このページは機械翻訳したものです。

8.14.3 一般的なスレッドの状態

次のリストは、レプリケーションなどの特殊なアクティビティーではなく、一般的なクエリーの処理に関連付けられた、スレッドの State 値を説明しています。 これらの多くは、サーバーのバグを見つけるためにのみ役立ちます。

• After create

  これは、スレッドがテーブル (内部一時テーブルも含む) を作成する際の、テーブルを作成する関数の最後に発生します。 何らかのエラーのためテーブルを作成できなかった場合でも、この状態が使われます。

• altering table

  サーバーはインプレース ALTER TABLE の実行中です。

• Analyzing

  スレッドは MyISAM テーブルのキー分布を計算しています (ANALYZE TABLE などで)。

• checking permissions

  スレッドは、サーバーがステートメントを実行するために必要な権限を持っているかどうかを確認しています。

• Checking table

  スレッドはテーブルチェック操作を実行しています。

• cleaning up

  スレッドは 1 つのコマンドを処理し、メモリーの解放と特定の状態変数のリセットを準備しています。

• closing tables

  スレッドは、変更されたテーブルデータをディスクにフラッシュし、使用されたテーブルをクローズしています。 これは高速の操作であるはずです。 そうでない場合は、ディスクがいっぱいでないか、ディスクが著しく頻繁に使用されていないかを確認してください。

• converting HEAP to ondisk

  スレッドは内部一時テーブルを MEMORY テーブルからディスク上のテーブルに変換しています。

• copy to tmp table

  スレッドは ALTER TABLE ステートメントを処理しています。 この状態は、新しい構造でテーブルが作成されたあと、ただし、それに行がコピーされる前に発生します。

  この状態のスレッドの場合、パフォーマンススキーマを使用してコピー操作の進行状況を取得できます。 セクション27.12.5「パフォーマンススキーマステージイベントテーブル」を参照してください。

• Copying to group table

  ステートメントの ORDER BY と GROUP BY の基準が異なる場合、行はグループによってソートされ、一時テーブルにコピーされます。

• Copying to tmp table

  サーバーはメモリー内の一時テーブルにコピーしています。

• Copying to tmp table on disk

  サーバーはディスク上の一時テーブルにコピーしています。 一時結果セットが大きくなりすぎました (セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください)。 その結果、スレッドは一時テーブルをインメモリーからディスクベースのフォーマットに変更して、メモリーを節約します。

• Creating index

  スレッドは MyISAM テーブルに対する ALTER TABLE ... ENABLE KEYS を処理しています。

• Creating sort index

  スレッドは内部一時テーブルを使用して解決される SELECT を処理しています。

• creating table

  スレッドはテーブルを作成しています。 これには一時テーブルの作成が含まれます。

• Creating tmp table

  スレッドはメモリー内またはディスク上に一時テーブルを作成しています。 テーブルがメモリー内に作成され、後でディスク上のテーブルに変換される場合、その操作中の状態は Copying to tmp table on disk です。

• committing alter table to storage engine

  サーバーはインプレース ALTER TABLE を終了し、結果をコミットしています。

• deleting from main table

  サーバーは複数テーブル削除の最初の部分を実行しています。 最初のテーブルからのみ削除し、別の (参照) テーブルからの削除に使用されるカラムとオフセットを保存しています。

• deleting from reference tables

  サーバーは複数テーブル削除の 2 番目の部分を実行しており、別のテーブルから一致した行を削除しています。

• discard_or_import_tablespace

  スレッドは ALTER TABLE ... DISCARD TABLESPACE または ALTER TABLE ... IMPORT TABLESPACE ステートメントを処理しています。

• end

  これは、ALTER TABLE、CREATE VIEW、DELETE、INSERT、SELECT、または UPDATE ステートメントの最後、ただしクリーンアップの前に発生します。

  end 状態では、次の操作が行われることがあります。

  • バイナリログへのイベントの書き込み

  • BLOB 用を含むメモリーバッファーの解放

• executing

  スレッドはステートメントの実行を開始しました。

• Execution of init_command

  スレッドは init_command システム変数の値のステートメントを実行しています。

• freeing items

  スレッドはコマンドを実行しました。 通常、この状態のあとは cleaning up になります。

• FULLTEXT initialization

  サーバーは自然言語全文検索を実行する準備をしています。

• init

  これは、ALTER TABLE、DELETE、INSERT、SELECT、または UPDATE ステートメントの初期化の前に発生します。 この状態のサーバーによって実行されるアクションには、バイナリログと InnoDB ログのフラッシュが含まれます。

• Killed

  だれかがスレッドに KILL ステートメントを送っており、スレッドは次に強制終了フラグをチェックしたときに中止するはずです。 フラグは MySQL の各主要ループ内でチェックされますが、場合によってはスレッドが停止するまでに少し時間がかかる場合があります。 スレッドがほかのスレッドにロックされている場合、強制終了はほかのスレッドがそのロックを解除するとすぐに有効になります。

• Locking system tables

  スレッドがシステムテーブル (タイムゾーンやログテーブルなど) をロックしようとしています。

• logging slow query

  スレッドはステートメントを低速クエリーログに書き込んでいます。

• login

  クライアントが正常に認証されるまでの接続スレッドの初期状態です。

• manage keys

  サーバーはテーブルインデックスを有効または無効にしています。

• Opening system tables

  スレッドがシステムテーブル (タイムゾーンやログテーブルなど) を開こうとしています。

• Opening tables

  スレッドはテーブルをオープンしようと試みています。 これは、何かにオープンを妨げられないかぎり、きわめて高速な手順であるはずです。 たとえば、ALTER TABLE または LOCK TABLE ステートメントは、そのステートメントが終了するまでテーブルのオープンを妨げることがあります。 table_open_cache 値が十分に大きいことをチェックすることも価値があります。

  システムテーブルの場合は、かわりに Opening system tables の状態が使用されます。

• optimizing

  サーバーはクエリーの初期最適化を実行しています。

• preparing

  この状態はクエリーの最適化中に発生します。

• Purging old relay logs

  スレッドは不要なリレーログファイルを削除しています。

• query end

  この状態は、クエリーを処理したあと、ただし freeing items 状態の前に発生します。

• Receiving from client

  サーバーはクライアントからパケットを読み取っています。

• Removing duplicates

  クエリーは、MySQL が早い段階で個別の操作を最適化できなくなるような方法で SELECT DISTINCT を使用していました。 このため、MySQL は結果をクライアントに送る前にすべての重複した行を削除するための追加の段階を必要とします。

• removing tmp table

  スレッドは SELECT ステートメントを処理したあとに内部一時テーブルを削除しています。 一時テーブルが作成されなかった場合、この状態は使用されません。

• rename

  スレッドはテーブルの名前を変更しています。

• rename result table

  スレッドは ALTER TABLE ステートメントを処理しており、新しいテーブルを作成し、元のテーブルを置き換えるためにその名前を変更しています。

• Reopen tables

  スレッドはテーブルのロックを取得しましたが、ロックの取得後、基盤となるテーブル構造が変更されたことを認識しました。 それはロックを解除し、テーブルをクローズして、再度オープンしようとしています。

• Repair by sorting

  修復コードはインデックスを作成するためにソートを使用しています。

• preparing for alter table

  サーバーはインプレース ALTER TABLE の実行を準備しています。

• Repair done

  スレッドは MyISAM テーブルのマルチスレッド修復を完了しました。

• Repair with keycache

  修復コードはキーキャッシュ経由で、1 つずつキーの作成を使用しています。 これは Repair by sorting よりはるかに遅くなります。

• Rolling back

  スレッドはトランザクションをロールバックしています。

• Saving state

  MyISAM テーブルの修復や分析などの操作で、スレッドは新しいテーブルの状態を .MYI ファイルヘッダーに保存しています。 状態には、行の数、AUTO_INCREMENT カウンタ、キー分布などの情報が含まれています。

• Searching rows for update

  スレッドは、すべての一致する行を更新する前に、それらを見つけるための第 1 フェーズを実行しています。 これは、UPDATE が、関連する行を見つけるために使用されるインデックスを変更している場合に、実行される必要があります。

• Sending data

  スレッドは SELECT ステートメントの行を読み取り、処理して、データをクライアントに送信しています。 この状態で行われる操作は、大量のディスクアクセス (読み取り) を実行する傾向があるため、特定のクエリーの存続期間にわたる最長時間実行状態になることがあります。

• Sending to client

  サーバーがクライアントにパケットを書き込んでいます。

• setup

  スレッドは ALTER TABLE 操作を開始しています。

• Sorting for group

  スレッドは GROUP BY を満たすためにソートを実行しています。

• Sorting for order

  スレッドは ORDER BY を満たすためにソートを実行しています。

• Sorting index

  スレッドは MyISAM テーブルの最適化操作中に、より効率的なアクセスのためにインデックスページをソートしています。

• Sorting result

  SELECT ステートメントの場合、これは Creating sort index と似ていますが、非一時テーブルに対するものです。

• starting

  ステートメントの実行開始時の最初のステージ。

• statistics

  サーバーはクエリー実行プランを開発するための統計を計算しています。 スレッドが長期間この状態にある場合、サーバーはディスクに依存してほかの作業を実行している可能性があります。

• System lock

  スレッドが mysql_lock_tables() を呼び出しましたが、以降スレッドの状態は更新されていません。 これは、多くの理由で発生する可能性がある非常に一般的な状態です。

  たとえば、スレッドがリクエストしようとしているか、テーブルの内部または外部システムロックを待機しています。 これは、InnoDB が LOCK TABLES の実行中にテーブルレベルのロックを待機している場合に発生することがあります。 この状態が外部ロックへのリクエストによって発生しており、同じ MyISAM テーブルにアクセスしている複数の mysqld サーバーを使用していない場合、--skip-external-locking オプションによって外部システムロックを無効にできます。 ただし、外部ロックはデフォルトで無効になっているため、このオプションは無効になっている可能性があります。 SHOW PROFILE の場合、この状態はスレッドがロックをリクエストしている (待機しているのではなく) ことを意味します。

  システムテーブルの場合は、かわりに Locking system tables の状態が使用されます。

• update

  スレッドはテーブルの更新を開始する準備ができています。

• Updating

  スレッドは更新する行を探していて、それらを更新しています。

• updating main table

  サーバーは複数テーブル更新の最初の部分を実行しています。 最初のテーブルのみを更新しており、別の (参照) テーブルの更新に利用されるカラムとオフセットを保存しています。

• updating reference tables

  サーバーは複数テーブル更新の 2 番目の部分を実行しており、ほかのテーブルから一致した行を更新しています。

• User lock

  スレッドは GET_LOCK() 呼び出しによってリクエストされたアドバイザリロックを、リクエストしようとしているか待機しています。 SHOW PROFILE の場合、この状態はスレッドがロックをリクエストしている (待機しているのではなく) ことを意味します。

• User sleep

  スレッドは SLEEP() 呼び出しを呼び出しました。

• Waiting for commit lock

  FLUSH TABLES WITH READ LOCK はコミットロックを待機しています。

• waiting for handler commit

  スレッドは、クエリー処理の他の部分に対するトランザクションのコミットを待機しています。

• Waiting for tables

  スレッドは、テーブルの基盤となる構造が変更され、その新しい構造を得るためにテーブルを再度オープンする必要があるという通知を受け取りました。 ただし、テーブルを再度オープンするには、ほかのすべてのスレッドが問題のテーブルをクローズするまで待機する必要があります。

  この通知は、別のスレッドが FLUSH TABLES か、問題のテーブルに次のステートメントのいずれかを使用した場合に、この通知が行われます: FLUSH TABLES tbl_name、ALTER TABLE、RENAME TABLE、REPAIR TABLE、ANALYZE TABLE、または OPTIMIZE TABLE。

• Waiting for table flush

  スレッドは FLUSH TABLES を実行しており、すべてのスレッドがテーブルを閉じるのを待機しているか、テーブルの基礎となる構造が変更されたため、新しい構造を取得するにはテーブルを再度開く必要があるという通知をスレッドが受け取りました。 ただし、テーブルを再度オープンするには、ほかのすべてのスレッドが問題のテーブルをクローズするまで待機する必要があります。

  この通知は、別のスレッドが FLUSH TABLES か、問題のテーブルに次のステートメントのいずれかを使用した場合に、この通知が行われます: FLUSH TABLES tbl_name、ALTER TABLE、RENAME TABLE、REPAIR TABLE、ANALYZE TABLE、または OPTIMIZE TABLE。

• Waiting for lock_type lock

  サーバーは、メタデータロックサブシステムからの THR_LOCK ロックまたはロックの取得を待機しています (lock_type はロックのタイプを示します)。

  この状態は、THR_LOCK の待機を示します:

  • Waiting for table level lock

  次の状態は、メタデータロックの待機を示します:

  • Waiting for event metadata lock

  • Waiting for global read lock

  • Waiting for schema metadata lock

  • Waiting for stored function metadata lock

  • Waiting for stored procedure metadata lock

  • Waiting for table metadata lock

  • Waiting for trigger metadata lock

  テーブルロックインジケータの詳細は、セクション8.11.1「内部ロック方法」 を参照してください。 メタデータのロックの詳細は、セクション8.11.4「メタデータのロック」 を参照してください。 ロック要求をブロックしているロックを確認するには、セクション27.12.13「パフォーマンススキーマロックテーブル」 で説明されているパフォーマンススキーマロックテーブルを使用します。

• Waiting on cond

  スレッドが条件が true になるのを待機している一般的な状態です。 特定の状態情報は使用できません。

• Writing to net

  サーバーはネットワークにパケットを書き込んでいます。