次のリストは、レプリケーションなどの特殊化した処理ではなく、一般的なクエリーの処理に関連付けられた、スレッドの
State
値を示します。これらの多くは、サーバーのバグを見つけるためだけに役立ちます。
この状態は、スレッドでテーブル (内部一時テーブルも含む) を作成する際、テーブルを作成する関数の最後に発生します。何らかのエラーのためテーブルを作成できなかった場合でも、この状態が使用されます。
スレッドは MyISAM
テーブルのキー分布を計算しています
(ANALYZE
TABLE
などで)。
スレッドは、サーバーがステートメントを実行するために必要な権限を持っているかどうかを確認しています。
スレッドがテーブルチェック操作を行っています。
スレッドは 1 つのコマンドの処理を完了しました。メモリーの解放と特定の状態変数をリセットする準備をしています。
スレッドは、変更されたテーブルデータをディスクにフラッシュし、使用されたテーブルを閉じています。この操作スピードは速いでしょう。もし速くなければ、ディスクがフルではないということと、ディスクがそれほど頻繁に使用されていないということを証明しなければいけません。
スレッドは内部一時テーブルを
MEMORY
テーブルからディスク上の
MyISAM
テーブルに変換しています。
スレッドは ALTER
TABLE
ステートメントを処理しています。この状態は、新しい構造でテーブルが作成されたあと、ただし、そのテーブルに行がコピーされる前に発生します。
もしステートメントが異なる
ORDER BY
と
GROUP BY
基準を持っていたら、行はグループによってソートされ、一時テーブルにコピーされます。
サーバーはメモリー内の一時テーブルにコピーしています。
サーバーはディスク上の一時テーブルにコピーしています。一時結果セットは
tmp_table_size
よりも大きく、スレッドはメモリーを保存するために一時テーブルをインメモリーからディスクベースフォーマットに変更しています。
スレッドは MyISAM
テーブルに対する ALTER
TABLE ... ENABLE KEYS
を処理しています。
スレッドは内部一時テーブルを使用して解決される
SELECT
を処理しています。
スレッドはテーブルを作成しています。これには一時テーブルの作成も含まれます。
スレッドはメモリー内またはディスク上に一時テーブルを作成しています。メモリー内に作成されたテーブルがあとでディスク上のテーブルに変換される場合、その操作中の状態は
Copying to tmp table on
disk
になります。
サーバーは複合テーブル削除の最初の部分を実行しています。最初のテーブルからの削除だけを行い、別の (参照) テーブルからの削除に利用されるカラムとオフセットを保存しています。
deleting from reference
tables
サーバーは複合テーブル削除の 2 番目の部分を行っており、別のテーブルから一致したテーブルを削除しています。
スレッドは ALTER TABLE ...
DISCARD TABLESPACE
または
ALTER TABLE ... IMPORT
TABLESPACE
ステートメントを処理しています。
この状態は、ALTER
TABLE
、CREATE
VIEW
、DELETE
、INSERT
、SELECT
、または
UPDATE
ステートメントの最後、ただしクリーンアップの前に発生します。
スレッドはステートメントの実行を開始しました。
スレッドは
init_command
システム変数の値に含まれているステートメントを実行しています。
スレッドはコマンドの実行を完了しました。通常、この状態のあとは
cleaning up
になります。
スレッドは
FLUSH
TABLES
を実行しており、すべてのスレッドがそのテーブルを閉じるのを待っています。
サーバーは自然言語フルテキストサーチを行う準備をしています。
この状態は、ALTER
TABLE
、DELETE
、INSERT
、SELECT
、または
UPDATE
ステートメントの初期化の前に発生します。
だれかがスレッドに
KILL
ステートメントを送り、そして次にキルフラッグを見つけた時異常終了するはずです。そのフラッグは
MySQL
内の主要な各ループ内で確認されますが、場合によってはスレッドが停止するまでに少し時間がかかる場合があります。もしスレッドが別のスレッドにロックされていると、停止作業は別のスレッドがそのロックを解除するとすぐに効果を発揮します。
クエリーは別のクエリーによってロックされています。
スレッドはステートメントを低速クエリーログに書き込んでいます。
この状態は SHOW
PROCESSLIST
に使用されます。
クライアントが正常に認証されるまでの接続スレッドの初期状態です。
スレッドはテーブルをオープンしようと試みています。この操作は、何かにオープンを邪魔されないかぎり、スピードが速いはずです。たとえば、ALTER
TABLE
か
LOCK
TABLE
ステートメントは、そのステートメントが終了するまでテーブルのオープンを邪魔することができます。
この状態はクエリーの最適化中に発生します。
スレッドは不要なリレーログファイルを削除しています。
この状態は、クエリーを処理したあと、ただし
freeing items
状態の前に発生します。
サーバーはネットワークからパケットを読み込んでいます。
クエリーは、MySQL
が早い段階で独特な操作を最適化することができなくなるような方法で
SELECT
DISTINCT
を利用していました。このため、MySQL
は結果をクライアントに送る前にすべての複製行を削除するための特別な段階を必要とします。
スレッドは
SELECT
ステートメントを処理したあとで内部一時テーブルを削除しています。一時テーブルが作成されていなかった場合、この状態は使用されません。
スレッドはテーブルの名前を変更しています。
スレッドは ALTER
TABLE
ステートメントを処理しています。新しいテーブルを作成し、元のテーブルを置き換えるためにその名前を変更しています。
スレッドはテーブルのためにロックを得ましたが、その後基礎となるテーブル構造が変更されたことに気が付きました。それはロックを解除し、テーブルを閉じ、そして再度オープンしようとしています。
修復コードはインデックスを作成するためにソートを利用しています。
スレッドは MyISAM
テーブルに対するマルチスレッドの修復を完了しました。
修復コードはキーキャッシュを通してキー作成を
1 つ 1 つ利用しています。これは
Repair by sorting
と比べるとかなり遅い作業です。
スレッドはトランザクションをロールバックしています。
MyISAM
テーブルの修復や分析などの操作で、スレッドは新しいテーブルの状態を
.MYI
ファイルヘッダーに保存しています。状態には、行の数、AUTO_INCREMENT
カウンタ、キー分布などの情報が含まれています。
スレッドは、すべての一致する行を更新する前にそれらを見つけるための第一段階を行っています。もし
UPDATE
が、関連する行を見つけるために利用されたインデックスを変更していれば、これが行われなければいけません。
Sending data
スレッドは
SELECT
ステートメントのために行を作成し、また、クライアントにデータを送っています。
スレッドは ALTER
TABLE
操作を開始しています。
スレッドは GROUP
BY
を満足させるためにソートを行っています。
スレッドは ORDER
BY
を満足させるためにソートを行っています。
スレッドは MyISAM
テーブルの最適化操作中にアクセス効率を向上させるためにインデックスページをソートしています。
これは
SELECT
ステートメントに関しては
Creating sort index
と同様ですが、テーブルが一時テーブルではありません。
サーバーはクエリー実行計画を開発する統計を計算しています。
スレッドは、テーブルに対する内部システムロックまたは外部システムロックを、要求しようとしているか待機しています。外部ロックの要求によってこの状態が発生している場合で、同じテーブルにアクセスする複数の
mysqld
サーバーを使用していないときは、--skip-external-locking
オプションで外部システムロックを無効にできます。ただし、外部ロックはデフォルトで無効になるため、このオプションには効果がない可能性があります。
System lock
のあとのスレッド状態です。スレッドは外部ロックの取得を完了し、内部テーブルロックを要求しようとしています。
スレッドは更新する行を探していて、それらを更新しています。
サーバーは複合テーブル更新の最初の部分を実行しています。最初のテーブルの更新だけを行い、別の (参照) テーブルの更新に利用されるカラムとオフセットを保存しています。
サーバーは複合テーブル更新の 2 番目の部分を行っており、別のテーブルから一致したテーブルを更新しています。
スレッドは
GET_LOCK()
呼び出しでアドバイザリロックを要求しようとしているか待機しています。SHOW
PROFILE
の場合、この状態はスレッドがロックを
(待機しているのではなく)
要求していることを意味します。
Waiting for
tables
、Waiting for
table
スレッドは、テーブルの基礎構造が変更され、その新しい構造を得るためにテーブルを再度オープンしなければいけないという通知を受け取りました。しかし、テーブルを再度オープンするには、ほかのすべてのスレッドが問題になっているテーブルを閉じるまで待たなければいけません。
もし別のスレッドが
FLUSH
TABLES
か、次にある問題のテーブル上のステートメントの中のひとつを利用すると、この通知が出されます。FLUSH
TABLES
、tbl_name
ALTER
TABLE
、RENAME
TABLE
、REPAIR
TABLE
、ANALYZE
TABLE
、または
OPTIMIZE
TABLE
。
スレッドが条件の成立を待機しているときの一般的な状態です。状態に関する詳細な情報は提供されません。
サーバーはネットワークにパケットを書き込んでいます。