# Aurora MySQL スレッド状態
<a name="AuroraMySQL.Reference.thread-states"></a>

以下は、Aurora MySQL の代表的な待機イベントです。

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

**クエリキャッシュのクエリのチェック**  
サーバーは、現在のクエリがクエリキャッシュに存在するかどうかをチェックしています。

**クリーンアップ**  
これは、作業は完了しているがクライアントによってまだ閉じられていない接続の最終状態です。最善の解決策は、コード内の接続を明示的に閉じることです。または、パラメータグループの `wait_timeout` に、より低い値を設定することもできます。

**テーブルを閉じる**  
スレッドは、変更されたテーブルデータをディスクにフラッシュし、使用されているテーブルを閉じています。高速操作ではない場合は、インスタンスクラスのネットワーク帯域幅に対するネットワーク帯域幅消費メトリックを確認します。また `table_open_cache` と `table_definition_cache` パラメータのパラメータ値が、十分なテーブルを同時に開ける状態かをチェックし、エンジンが頻繁にテーブルを開いたり閉じたりする必要がないようにします。これらのパラメータは、インスタンスのメモリ消費量に影響します。

**HEAP を MyISAM に変換する**  
クエリは、一時テーブルをインメモリからディスク上に変換しています。この変換は、クエリ処理の中間ステップで MySQL によって作成された一時テーブルがメモリに対して大きすぎるため、必要になります。`tmp_table_size` と `max_heap_table_size` の値をチェックします。それ以降のバージョンでは、このスレッド状態名は `converting HEAP to ondisk` です。

**HEAP をオンディスクに変換する**  
スレッドは、内部一時テーブルをインメモリテーブルからディスク上のテーブルに変換しています。

**tmp テーブルにコピーする**  
スレッドが `ALTER TABLE` ステートメントを処理中です。この状態は、新しい構造を持つテーブルが作成された後、ローがそのテーブルにコピーされる前に発生します。この状態のスレッドの場合、パフォーマンススキーマを使用して、コピー操作の進行状況に関する情報を取得できます。

**ソートインデックスの作成**  
Aurora MySQL は、既存のインデックスを使用して クエリの `ORDER BY` および `GROUP BY` 句を満たすことができないため、ソートを実行しています。詳細については、「[ソートインデックスの作成](ams-states.sort-index.md)」を参照してください。

**テーブルの作成**  
スレッドは、永続テーブルまたは一時テーブルを作成しています。

**遅延コミット ok 完了**  
Aurora MySQL の非同期コミットが承認を受け取り、完了しました。

**遅延コミット ok スタートしました**  
Aurora MySQL スレッドは非同期コミットプロセスをスタートしましたが、確認を待っています。これは通常、トランザクションの本物のコミット時間です。

**遅延送信 ok 完了**  
接続に関連付けられている Aurora MySQL ワーカースレッドは、応答がクライアントに送信されている間に解放できます。スレッドは他の作業をスタートできます。ステータス `delayed send ok`は クライアントへの非同期確認が完了したことを示します。

**遅延送信 「ok」 をスタートしました**  
Aurora MySQL ワーカースレッドがクライアントに非同期で応答を送信し、他の接続で自由に作業できるようになりました。トランザクションは、まだ確認されていない非同期コミットプロセスをスタートしました。

**実行中**  
スレッドはステートメントの実行をスタートしました。

**アイテムを解放する**  
スレッドがコマンドを実行しました。この状態中に行われた項目の解放には、クエリキャッシュが含まれます。この状態は通常、クリーンアップが続きます。

**初期化**  
この状態は、`ALTER TABLE`、`DELETE`、`INSERT`、`SELECT`、または `UPDATE` ステートメントの初期化前に発生します。この状態のアクションには、バイナリログまたは InnoDB ログのフラッシュ、クエリキャッシュのクリーンアップが含まれます。

**ソースはすべてのバイナリログをレプリカに送信し、さらに更新を待っています**  
プライマリノードはレプリケーションの一部を終了しました。スレッドは、バイナリログ (binlog) に書き込むことができるように、より多くのクエリが実行されるのを待っています。

**テーブルを開く**  
スレッドがテーブルを開こうとしている。`ALTER TABLE` または `LOCK TABLE` ステートメントを終了する必要がある場合や、 `table_open_cache` の値を超える場合を除いて、このオペレーションは早いです。

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

**準備**  
この状態は、クエリの最適化中に発生します。

**クエリ終了**  
この状態は、クエリの処理後、アイテム解放状態の前に発生します。

**重複を除去する**  
Aurora MySQL は クエリの初期段階で`DISTINCT` オペレーションを最適化できませんでした。Aurora MySQL は、結果をクライアントに送信する前に、重複した行をすべて削除する必要があります。

**更新の行の検索**  
スレッドは更新する前に一致する行をすべて検索しています。この段階は、エンジンが行の検索に使用するインデックスを `UPDATE` が変更している時に必要です。

**バイナリログイベントをスレーブに送信する**  
スレッドはバイナリログからイベントを読み取り、それをレプリカに送信しています。

**キャッシュされた結果をクライアントに送信する**  
サーバーは、クエリキャッシュからクエリの結果を取得し、それをクライアントに送信しています。

**データの送信**  
スレッドは、`SELECT` ステートメントの行を読み取り、処理していますが、クライアントへのデータの送信はまだスタートされていません。このプロセスでは、クエリを満たすために必要な結果が含まれているページを特定します。詳細については、「[データの送信](ams-states.sending-data.md)」を参照してください。

**クライアントに送信する**  
サーバーはクライアントにパケットを書き込んでいます。以前のバージョンの MySQL では、この待機イベントは `writing to net` としてラベル付けされていました。

**スタート中**  
これは、ステートメントの実行スタートの初期の段階です。

**統計**  
サーバーは統計を計算して、クエリ実行プランを開発しています。スレッドが長時間この状態にある場合、サーバーは他の作業の実行中にディスクバインドされている可能性があります。

**クエリキャッシュに結果を格納する**  
サーバーは、クエリの結果をクエリキャッシュに格納しています。

**システムロック**  
スレッドは `mysql_lock_tables` を呼び出しましたが、呼び出し以降、スレッドの状態は更新されていません。この一般的な状態は多くの理由で発生します。

**更新**  
スレッドはテーブルの更新をスタートする準備をしています。

**更新中**  
スレッドは行を検索し、更新中です。

**ユーザーロック**  
スレッドは `GET_LOCK` を発行しました。スレッドがアドバイザリロックを要求して待っているか、リクエストを計画しています。

**さらに更新を待っている**  
プライマリノードはレプリケーションの一部を終了しました。スレッドは、バイナリログ (binlog) に書き込むことができるように、より多くのクエリが実行されるのを待っています。

**スキーマメタデータのロックを待っています**  
これは、メタデータのロックを待ちます。

**ストアド関数のメタデータのロックを待っています**  
これは、メタデータのロックを待ちます。

**ストアドプロシージャのメタデータのロックを待っています。**  
これは、メタデータのロックを待ちます。

**テーブルフラッシュを待っています。**  
スレッドが実行中です`FLUSH TABLES`そして、すべてのスレッドがテーブルを閉じるのを待っています。または、スレッドは、テーブルの基になる構造が変更されたという通知を受信したため、新しい構造を取得するにはテーブルを再度開く必要があります。テーブルを再度開くには、スレッドは他のすべてのスレッドがテーブルを閉じるまで待機する必要があります。この通知は、別のスレッドがテーブルで次のいずれかのステートメントを使用している場合に発生します。`FLUSH TABLES`、`ALTER TABLE`、`RENAME TABLE`、`REPAIR TABLE`、`ANALYZE TABLE`、 または`OPTIMIZE TABLE`。

**テーブルレベルのロックを待っています。**  
あるセッションがテーブルのロックを保持し、別のセッションが同じテーブルで同じロックを取得しようとします。

**テーブルメタデータのロックを待っています。**  
Aurora MySQL は、メタデータロックを使用して、データベースオブジェクトへの同時アクセスを管理し、データの整合性を確保します。この待機イベントでは、あるセッションがテーブルのメタデータロックを保持し、別のセッションが同じテーブルで同じロックを取得しようとします。パフォーマンススキーマが有効になっている場合、このスレッドの状態は待機イベント `synch/cond/sql/MDL_context::COND_wait_status` として報告されます。

**ネットへの書き込み**  
サーバーはネットワークにパケットを書き込んでいます。それ以降のバージョンの MySQL では、この待機イベントには `Sending to client` というラベルが付けられます。