# Aurora MySQL の待機イベント
<a name="AuroraMySQL.Reference.Waitevents"></a>

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

**注記**  
待機イベントを使用して Aurora MySQL のパフォーマンスを調整する方法については、「[待機イベントを使用した Aurora MySQL のチューニング](AuroraMySQL.Managing.Tuning.wait-events.md)」を参照してください。  
MySQL の待機イベントで使用される命名規則については、MySQL ドキュメントの「[Performance Schema インストゥルメント命名規則](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html)」を参照してください。

**cpu**  
実行可能なアクティブな接続の数が vCPUs 数よりも一貫して多くなります。詳細については、「[cpu](ams-waits.cpu.md)」を参照してください。

**io/aurora\$1redo\$1log\$1flush**  
セッションは Aurora ストレージにデータを保持しています。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。詳細については、「[io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)」を参照してください。

**io/aurora\$1respond\$1to\$1client**  
Aurora MySQL バージョン 2.10.2 以降の 2.10 バージョン、2.09.3 以降の 2.09 バージョン、2.07.7 以降の 2.07 バージョンの場合、クエリ処理が完了すると、結果がアプリケーションクライアントに返されます。DB インスタンスクラスのネットワーク帯域幅と、返される結果セットのサイズを比較します。また、クライアント側の応答時間もチェックしてください。クライアントが応答せず、TCP パケットを処理できない場合、パケットドロップと TCP 再送信が発生する可能性があります。この状況は、ネットワーク帯域幅に悪影響を及ぼします。2.10.2、2.09.3、2.09.3、および 2.07.7 より前のバージョンでは、待機イベントにアイドル時間が誤って含まれます。この待機が目立つときにデータベースをチューニングする方法については、[io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) を参照してください。

**io/file/csv/data**  
スレッドは Comma Separated Value (CSV) 形式でテーブルに書き込みます。CSV テーブルの使用状況を確認してください。通常、このイベントはテーブルでの `log_output` の設定に伴って発生します。

**io/file/sql/binlog**  
スレッドは、ディスクに書き込まれるバイナリログ (binlog) ファイルを待っています。

**io/redo\$1log\$1flush**  
セッションは Aurora ストレージにデータを保持しています。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。詳細については、「[io/redo\$1log\$1flush](ams-waits.io-redologflush.md)」を参照してください。

**io/socket/sql/client\$1connection**  
`mysqld` プログラムは受信する新規クライアント接続を処理するためのスレッド作成でビジー状態です。詳細については、「[io/socket/sql/client\$1connection](ams-waits.client-connection.md)」を参照してください。

**io/table/sql/handler**  
エンジンは、テーブルへのアクセスを待っています。このイベントは、データがバッファプールにキャッシュされているか、ディスク上でアクセスされているかにかかわらず、発生します。詳細については、「[io/table/sql/handler](ams-waits.waitio.md)」を参照してください。

**lock/table/sql/handler**  
この待機イベントは、テーブルロック待機イベントハンドラです。Performance Schema の原始的イベントと分子的イベントの詳細については、MySQL ドキュメントの [Performance Schema の原子的および分子的イベント](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html)を参照してください。

**synch/cond/innodb/row\$1lock\$1wait**  
複数のデータ操作言語 (DML) ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md)」を参照してください。

**synch/cond/innodb/row\$1lock\$1wait\$1cond**  
複数の DML ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md)」を参照してください。

**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**  
スレッドは、テーブルのメタデータロックを待っています。エンジンは、このタイプのロックを使用して、データベーススキーマへの同時アクセスを管理し、データの整合性を確保します。詳細については、MySQL ドキュメントの「[ロック操作の最適化](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html)」を参照してください。この待機が目立つときにデータベースをチューニングする方法については、[synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) を参照してください。

**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**  
バイナリログを有効にしている。高いコミットスループット、多数のトランザクションがコミットされている、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログレプリケーションや `aurora_binlog_*` パラメータの代わりにグローバルデータベースを使用します。

**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**  
複数の DML ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)」を参照してください。

**synch/mutex/innodb/buf\$1pool\$1mutex**  
バッファプールが、ワーキング データ セットを保持するのに十分な大きさではありません。または、ワークロードが特定のテーブルからページにアクセスし、バッファプール内で競合が発生します。詳細については、「[synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md)」を参照してください。

**synch/mutex/innodb/fil\$1system\$1mutex**  
プロセスは、テーブルスペースのメモリキャッシュへのアクセスを待っています。詳細については、「[synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md)」を参照してください。

**synch/mutex/innodb/trx\$1sys\$1mutex**  
オペレーションは、一貫した、または制御された方法で InnoDB 内のトランザクション ID をチェック、更新、削除、または追加しています。これらの操作は `trx_sys` mutex 呼び出しを必要とします。これはパフォーマンススキーマインストルメンテーションによって追跡されます。操作には、データベースの起動時またはシャットダウン時のトランザクションシステムの管理、ロールバック、クリーンアップの取り消し、行の読み取りアクセス、およびバッファプールのロードが含まれます。トランザクション数が多い高データベース ロードは、この待機イベントの頻繁な発生につながります。詳細については、「[synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md)」を参照してください。

**synch/mutex/mysys/key\$1cache:: cache\$1lock**  <a name="key-cache.cache-lock"></a>
`keycache->cache_lock` mutex は MyISAM テーブルのキーキャッシュへのアクセスを制御します。Aurora MySQL では MyISAM テーブルを使用して永続データを保存することはできませんが、内部一時テーブルの保存に使用されます。状況によっては、一時テーブルがメモリに収まらなくなるとディスクに書き込まれることがあるため、`created_tmp_tables` または `created_tmp_disk_tables` ステータスカウンターを確認することを検討してください。

**synch/mutex/sql/file\$1as\$1table:: LOCK\$1offsets**  
エンジンは、テーブルメタデータファイルを開いたり作成したりするときに、このミューテックスを取得します。この待機イベントが過剰な頻度で発生すると、作成またはオープンされているテーブルの数が急増しています。

**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**  
エンジンは、`reset_size`、`detach_contents`、または `add_contents` のようなオペレーションを、オープンテーブルを追跡する内部構造上で実行しながら、このミューテックスを取得します。ミューテックスは、リストの内容へのアクセスを同期します。この待機イベントが高頻度で発生すると、以前にアクセスされたテーブルのセットが突然変化したことを示します。エンジンは、新しいテーブルにアクセスするか、以前にアクセスしたテーブルに関連するコンテキストを解放する必要があります。

**synch/mutex/sql/LOCK\$1open**  
セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「[MySQL でのテーブルのオープンとクローズの方法](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)」を参照してください。

**synch/mutex/sql/LOCK\$1table\$1cache**  
セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「[MySQL でのテーブルのオープンとクローズの方法](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)」を参照してください。

**synch/mutex/sql/LOG**  
この待機イベントの場合、ログロックの待機中のスレッドがあります。例えば、スレッドは、スロークエリログファイルに書き込むためにロックを待っている場合があります。

**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**  
この待機イベントの場合、バイナリログにコミットする目的でロック取得を待機中のスレッドがあります。変化率が非常に高いデータベースではバイナリログ記録の競合が発生する場合がありえます。使用している MySQL のバージョンによっては、バイナリログの整合性と耐久性の高さを保護するために使用される特定のロックがあります。RDS for MySQL の場合、バイナリログはレプリケーションと自動バックアッププロセスに使用されます。Aurora MySQL の場合、バイナリログはネイティブのレプリケーションやバックアップに必要ありません。バイナリログはデフォルトで無効になっていますが、これを有効にして外部のレプリケーションや変更データのキャプチャに使用できます。詳細については、MySQL ドキュメントの「[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)」を参照してください。

**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1dump\$1thread\$1metrics\$1collection**  
バイナリログ記録がオンの場合、エンジンはアクティブなダンプスレッドのメトリクスをエンジンエラーログと内部オペレーションマップに出力する際、このミューテックスを取得します。

**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1inactive\$1binlogs\$1map**  
バイナリログ記録がオンの場合、エンジンは最新のバイナリログファイルのリストに追加したり、そこから削除したり、検索したりする際に、このミューテックスを取得します。

**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1io\$1cache**  
バイナリログがオンの場合、エンジンは Aurora binlog IO キャッシュ操作(割り当て、サイズ変更、解放、書き込み、読み取り、パージ、およびキャッシュ情報へのアクセス) 中にこのミューテックスを取得します。このイベントが頻繁に発生する場合、エンジンは binlog イベントが格納されているキャッシュにアクセスしています。待機時間を短縮するには、コミットを減らします。複数のステートメントを 1 つのトランザクションにグループ化してみてください。

**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**  
バイナリログを有効にしている。高いコミットスループット、多数のコミットしているトランザクション、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログ レプリケーションや `aurora_binlog_*` パラメータの代わりにグローバルデータベースを使用します。

**synch/mutex/sql/server\$1thread:: LOCK\$1sync**  
ミューテックス `SERVER_THREAD::LOCK_sync` はファイル書き込みスレッドのスケジューリング、処理、または起動中に取得されます。この待機イベントが過剰に発生すると、データベース内の書き込みアクティビティが増加していることを示します。

**synch/mutex/sql/TABLESPACES:lock**  
エンジンは、作成、削除、トランケート、および拡張のテーブルスペース オペレーション中に `TABLESPACES:lock` ミューテックスを取得します。この待機イベントが過剰に発生すると、テーブルスペース操作の頻度が高いことを示します。例として、大量のデータをデータベースにロードしています。

**synch/rwlock/innodb/dict**  
この待機イベントの場合、InnoDB データディクショナリに保持されている rwlock を待機中のスレッドがあります。

**synch/rwlock/innodb/dict\$1operation\$1lock**  
この待機イベントの場合、InnoDB データディクショナリのオペレーションのロックを保持しているスレッドがあります。

**synch/rwlock/innodb/dict sys RW lock**  
データ定義言語コード (DDLs) 内の多数の同時データ制御言語ステートメント (DCLs) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDL への依存度を下げます。

**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**  
複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。

**synch/sxlock/innodb/dict\$1operation\$1lock**  
データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。

**synch/sxlock/innodb/dict\$1sys\$1lock**  
データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。

**synch/sxlock/innodb/hash\$1table\$1locks**  
セッションは、バッファプール内のページを見つけることができませんでした。エンジンは、ファイルを読み取るか、バッファプールの最も長い時間使われていない (LRU) リストを変更する必要があります。バッファキャッシュのサイズを増やし、関連するクエリのアクセスパスを改善することを検討してください。

**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**  
複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。

**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**  
この待機イベントは、セッションがセッション一時テーブルスペースのプールを管理するためのミューテックスの取得を待機しているときに発生します。

同期待機イベントのトラブルシューティングの詳細は、「[Performance Insights で SYNCH 待機イベントを待機しているアクティブセッションの数が多いことが MySQL DB インスタンスに表示されているのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/)」を参照してください。