# Aurora MySQL のチューニング
待機イベントとスレッドの状態は、Aurora MySQL の重要なチューニングツールです。セッションがリソースを待っている理由や、何を実行しているのかを知ることができれば、ボトルネックを減少できます。このセクションの情報を使用して、考えられる原因と修正措置を見つけることができます。
Amazon DevOps Guru for RDS は、Aurora MySQL データベースに、後でさらに大きな問題を引き起こす可能性がある問題条件があるかどうかを事前に判断できます。Amazon DevOps Guru for RDS は、是正措置の説明と推奨事項をプロアクティブインサイトで発行します。このセクションには、一般的な問題に関するインサイトが含まれています。
**重要**
このセクションの待機イベントとスレッドの状態は、Aurora MySQL に固有です。このセクションの情報は Amazon Aurora の調整にのみ使用し、Amazon RDS for MySQL には使用しないでください。
このセクションの待機イベントの一部は、これらのデータベースエンジンのオープンソースバージョンに対応するものがありません。他の待機イベントの名前は、オープンソースエンジンのイベントと同じですが、動作が異なります。例えば、Amazon Aurora ストレージはオープンソースストレージとは異なる動作をするため、ストレージ関連の待機イベントは異なるリソース条件を示します。
**Topics**
+ [Aurora MySQL チューニングの基本的な概念](AuroraMySQL.Managing.Tuning.concepts.md)
+ [待機イベントを使用した Aurora MySQL のチューニング](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [スレッド状態を使用した Aurora MySQL のチューニング](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [Amazon DevOps Guru のプロアクティブインサイトによる Aurora MySQL のチューニング](MySQL.Tuning.proactive-insights.md)
# Aurora MySQL チューニングの基本的な概念
Aurora MySQL データベースを調整する前に、待機イベントとスレッドの状態はどうなっているか、またその発生理由を確認してください。InnoDB ストレージエンジンを使用するときは、Aurora MySQL の基本的なメモリとディスクアーキテクチャも確認してください。便利なアーキテクチャ図表については、「[MySQL リファレンスマニュアル](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html)」を参照してください。
**Topics**
+ [Aurora MySQL の待機イベント](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Aurora MySQL スレッド状態](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Aurora MySQL メモリ](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Aurora MySQL プロセス](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Aurora MySQL の待機イベント
*待機イベント*はセッションが待っているリソースを示します。例えば、待機イベント `io/socket/sql/client_connection` はスレッドが新しい接続を処理中であることを示します。セッションが待機する一般的なリソースには、次のものがあります。
+ バッファへのシングルスレッドアクセス (例えば、セッションがバッファを変更しようとした場合など)
+ 別のセッションによって現在ロックされている行
+ 読み込まれたデータファイル
+ ログファイルの書き込み
例えば、クエリを満たすために、セッションで完全なテーブルスキャンを実行することがあります。データがまだメモリ上にない場合、セッションはディスク I/O が完了するまで待機します。バッファがメモリに読み込まれるときは、他のセッションが同じバッファにアクセスしているため、セッションは待機しなければならないことがあります。データベースは、事前定義された待機イベントを使用して待機を記録します。これらのイベントはカテゴリに分類されます。
待機イベント自体では、パフォーマンスの問題は表示されません。例えば、要求されたデータがメモリ上にない場合は、ディスクからデータを読み出す必要があります。あるセッションが更新のために行をロックすると、別のセッションはその行を更新できるようにロック解除されるまで待機します。コミットは、ログファイルへの書き込みが完了するまで待機する必要があります。待機は、データベースが正常に機能するために不可欠です。
一般的に、大量の待機イベントはパフォーマンスの問題を示します。そのような場合、待機イベントデータを使用して、セッションが時間を費やしている場所を特定できます。例えば、通常は分単位で実行されるレポートが数時間実行される場合、合計待機時間に最も多く寄与する待機イベントを特定できます。上位の待機イベントの原因を特定できる場合は、パフォーマンス向上のための変更を実行できることがあります。例えば、別のセッションによってロックされている行でセッションが待っている場合、ロックセッションを終了します。
## Aurora MySQL スレッド状態
*一般的なスレッド状態*は`State`一般的なクエリ処理に関連付けられている値です。例えばスレッドの状態 `sending data` は、スレッドがクエリの行を読み取り、フィルタリングして正しい結果セットを判断していることを示します。
スレッド状態を使用すると、待機イベントの使用方法と同じような仕様で Aurora MySQL を調整できます。例えば`sending data` の頻繁な発生は通常、クエリがインデックスを使用していないことを示します。スレッド状態の詳細については、*MySQL リファレンスマニュアル*の[一般的なスレッドステート](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html)を参照してください。
Performance Insights を使用する場合、以下の条件のいずれかに当てはまります。
+ パフォーマンススキーマがオンになっている — Aurora MySQL はスレッド状態ではなく待機イベントを表示します。
+ パフォーマンススキーマがオンになっていない — Aurora MySQL はスレッド状態を表示します。
パフォーマンススキーマは、自動管理に設定することをお勧めします。パフォーマンススキーマは、潜在的なパフォーマンスの問題を調査するための追加のインサイトと優れたツールを提供します。詳細については、[Aurora MySQL における Performance Insights のPerformance Schema の概要](USER_PerfInsights.EnableMySQL.md) を参照してください。
## Aurora MySQL メモリ
Aurora MySQL では、最も重要なメモリ領域はバッファプールとログバッファです。
**Topics**
+ [バッファプール](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### バッファプール
*バッファプール*は Aurora MySQL がテーブルとインデックスデータをキャッシュする共有メモリ領域です。クエリはディスクから読み取ることなく、頻繁に使用されるデータにメモリから直接アクセスできます。
バッファプールは、ページのリンクリストとして構成されています。*ページ*は複数の行を保持できます。Aurora MySQL は、プールからページをエージングアウトするために、最近最も使用されていない (LRU) アルゴリズムを使用します。
詳細については、*MySQL リファレンスマニュアル*の「[Buffer Pool](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html)」(バッファプール) を参照してください。
## Aurora MySQL プロセス
Aurora MySQL は Aurora PostgreSQL とは大きく異なるプロセスモデルを使用しています。
**Topics**
+ [MySQLサーバー (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [スレッド](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [スレッドプール](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### MySQLサーバー (mysqld)
MySQL サーバーは mysqld という名前の単一のオペレーティングシステムプロセスです。MySQL サーバーは追加のプロセスを生成しません。したがって Aurora MySQL データベースは、 mysqld を使用してほとんどの作業を実行します。
MySQL サーバーが起動すると、MySQL クライアントからのネットワーク接続をリッスンします。クライアントがデータベースに接続すると、mysqld はスレッドを開きます。
### スレッド
接続マネージャースレッドは、各クライアント接続を専用スレッドに関連付けます。このスレッドは、認証を管理し、ステートメントを実行し、結果をクライアントに返します。接続マネージャは、必要に応じて新しいスレッドを作成します。
*スレッドキャッシュ*は使用可能なスレッドのセットです。接続が終了すると、キャッシュがいっぱいでない場合、MySQL はスレッドをスレッドキャッシュに返します。`thread_cache_size` システム可変は、スレッドキャッシュのサイズを決定します。
### スレッドプール
*スレッドプール*は複数のスレッドグループで構成されています。各グループは一連のクライアント接続を管理します。クライアントがデータベースに接続すると、スレッドプールはラウンドロビン方式でスレッドグループに接続を割り当てます。スレッドプールは接続とスレッドを分離します。接続と、それらの接続から受信した文を実行するスレッドの間には、固定された関係はありません。
# 待機イベントを使用した Aurora MySQL のチューニング
次の表は、パフォーマンス問題を最もよく示す Aurora MySQL の待機イベントをまとめたものです。以下の待機イベントは、[Aurora MySQL の待機イベント](AuroraMySQL.Reference.Waitevents.md) のリストのサブセットです。
| 待機イベント | 説明 |
| --- | --- |
| [cpu](ams-waits.cpu.md) | このイベントは、スレッドが CPU でアクティブであるか、CPU を待っているときに発生します。 |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | このイベントは、セッションが永続データを Aurora ストレージに書き込むときに発生します。 |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。 |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | このイベントは、セッションが永続データを Aurora ストレージに書き込むときに発生します。 |
| [io/socket/sql/client\$1connection](ams-waits.client-connection.md) | このイベントは、スレッドが新しい接続を処理している最中のときに発生します。 |
| [io/table/sql/handler](ams-waits.waitio.md) | このイベントは、作業がストレージエンジンに委任されたときに発生します。 |
| [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md) | このイベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。 |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | このイベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。 |
| [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) | このイベントは、テーブルメタデータロックに待機中のスレッドがあるときに発生します。 |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | このイベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。 |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | このイベントは、スレッドがメモリ内のページにアクセスするために InnoDB バッファプールのロックを取得したときに発生します。 |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | このイベントは、セッションがテーブルスペースのメモリキャッシュへのアクセスを待っているときに発生します。 |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | このイベントは、大量のトランザクションで高いデータベースアクティビティがある場合に発生します。 |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | このイベントは、バッファプール内には見つからないページをファイルから読み込む必要がある場合に発生します。 |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | このイベントは、セッションがセッション一時テーブルスペースのプールを管理するためのミューテックスの取得を待機しているときに発生します。 |
# cpu
`cpu` 待機イベントは、スレッドが CPU でアクティブな場合、または CPU を待っている際に発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.cpu.context.supported)
+ [Context](#ams-waits.cpu.context)
+ [待ち時間増加の考えられる原因](#ams-waits.cpu.causes)
+ [アクション](#ams-waits.cpu.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
すべての vCPU に対して、接続はこの CPU 上で動作を実行できます。状況によっては、実行可能なアクティブな接続の数が vCPUs の数よりも多くなります。この不均衡により、接続が CPU リソースを待機することになります。アクティブな接続の数が vCPUs の数よりも常に多い場合、インスタンスに CPU 競合が発生します。この競合により、`cpu` 待機イベントが発生します。
**注記**
CPU の Performance Insights メトリクスは `DBLoadCPU` です。`DBLoadCPU` の値は CloudWatch メトリクス `CPUUtilization` の値とは異なる場合があります。後者のメトリクスは、データベースインスタンスのハイパーバイザーから収集されます。
Performance Insights OS メトリクスは、CPU 使用率に関する詳細情報を提供します。例えば、以下のメトリクスを表示できます。
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights は、データベースエンジンによる CPU 使用率を `os.cpuUtilization.nice.avg` として報告します。
## 待ち時間増加の考えられる原因
このイベントが通常よりも多く発生し、パフォーマンス問題を示している可能性がある場合、典型的な原因は次のとおりです。
+ 分析クエリ
+ 高パラレルトランザクション
+ 実行時間が長いトランザクション
+ *ログインストーム*として知られる、接続数の急激な増加。
+ コンテキスト切り替えの増加
## アクション
`cpu` 待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。パフォーマンスが低下した場合にのみ、このイベントに応答します。
CPU 使用率の増加の原因に応じて、次の戦略を検討してください。
+ ホストの CPU 容量を増やします。このアプローチは通常、テンポラリ救済しか与えません。
+ 潜在的な最適化のためのトップクエリを特定します。
+ 読み取り専用ワークロードをリーダーノードにリダイレクトします (該当する場合)。
**Topics**
+ [問題の原因となっているセッションまたはクエリを特定します。](#ams-waits.cpu.actions.az-vpc-subnet)
+ [高い CPU ワークロードを分析して最適化する](#ams-waits.cpu.actions.db-instance-class)
### 問題の原因となっているセッションまたはクエリを特定します。
セッションとクエリを見つけるには、Performance Insights の**トップ SQL** の表で、CPU ロードが最も高い SQL ステートメントを探します。詳細については、「[Performance Insights ダッシュボードを使用してメトリクスを分析する](USER_PerfInsights.UsingDashboard.md)」を参照してください。
通常、1 つまたは 2 つの SQL ステートメントは CPU サイクルの大半を消費します。これらのステートメントを中心に確認してください。DB インスタンスに 2 つの vCPUs があり、DB ロードが平均 3.1 のアクティブセッション (AAS) がすべて CPU 状態にあるとします。この場合、インスタンスは CPU バインドされています。以下の戦略を検討して下さい。
+ より多くの vCPUs を持つより大きなインスタンスクラスにアップグレードします。
+ クエリを調整して CPU ロードを下げます。
この例では、上位 SQL クエリの DB ロードが 1.5 AAS で、すべて CPU 状態です。別の SQL ステートメントの CPU 状態では 0.1 のロードがあります。この例では、lowest-load SQL 文を停止しても、データベースのロードは大幅に軽減されません。ただし、2 つの高ロードクエリを最適化して 2 倍の効率が得られると、CPU のボトルネックがなくなります。1.5 AAS の CPU ロードを 50% 減らすと、各ステートメントの AAS は 0.75 に減少します。CPU に費やされた DB ロードの合計は 1.6 AAS になりました。この値は、vCPU の最大ラインの 2.0 を下回っています。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。また AWS Support 記事 [Amazon RDS for MySQL インスタンスで CPU 使用率が高い CPU 使用率のトラブルシューティングと解決方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)も参照してください。
### 高い CPU ワークロードを分析して最適化する
CPU 使用率を増加させているクエリを特定したら、それらを最適化するか、接続を終了します。次の例は、接続の終了方法を解説しています。
```
CALL mysql.rds_kill(processID);
```
詳細については、「[mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill)」を参照してください。
セッションを終了すると、アクションによって長いロールバックがトリガーされることがあります。
#### クエリを最適化するためのガイドラインに従う
クエリを最適化するには、次のガイドラインを考慮してください。
+ `EXPLAIN` ステートメントを実行します。
このコマンドは、クエリの実行に関連する個々のステップを示しています。詳細については、MySQL ドキュメントの[「EXPLAIN を使用したクエリの最適化」](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html)を参照してください。
+ `SHOW PROFILE` ステートメントを実行します。
このステートメントを使用して、現在のセッション中に実行されるステートメントのリソース使用状況を示すプロファイル詳細を確認します。詳細については、MySQL ドキュメントの [SHOW PROFILE ステートメント](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html)を参照してください。
+ `ANALYZE TABLE` ステートメントを実行します。
このステートメントを使用して、CPU を大量に消費するクエリによってアクセスされるテーブルのインデックス統計を更新します。ステートメントを分析することで、オプティマイザが適切な実行プランを選択するのに役立ちます。詳細については、MySQL ドキュメントの [ANALYZE TABLE ステートメント](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html)を参照してください。
#### CPU 使用率を改善するためのガイドラインに従ってください
データベースインスタンスの CPU 使用率を向上させるには、次のガイドラインに従ってください。
+ すべてのクエリが適切なインデックスを使用していることを確認します。
+ Aurora パラレルクエリを使用できるかどうかを調べます。このテクニックを使うと、関数処理、行のフィルタリング、および `WHERE` 句のプロジェクションをプッシュダウンすることにより、ヘッドノードの CPU 使用率を削減することができます。
+ 1 秒あたりの SQL 実行数が予想されるしきい値と合っているかを調べます。
+ インデックスのメンテナンスまたは新規インデックスの作成が、本番ワークロードで必要な CPU サイクルにかかるかどうかを調べます。ピークアクティビティ時間外のメンテナンスアクティビティをスケジュールします。
+ パーティショニングを使用してクエリデータセットを削減できるかどうかを調べます。詳細については、ブログの投稿記事 [統合ワークロードに向けて Amazon Aurora with MySQL の互換性を計画、最適化する方法](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/)を参照してください。
#### 接続ストームをチェックする
`DBLoadCPU` メトリクスはそれほど高くはないが `CPUUtilization` メトリクスが高い場合、CPU 使用率が高い原因はデータベースエンジンの外部にあります。典型的な例はコネクションストームです。
以下の条件に該当するかどうかを確認してください。
+ Performance Insights `CPUUtilization` メトリックスと Amazon CloudWatch `DatabaseConnections` メトリクスの両方で増加が見られる。
+ CPU 内のスレッド数が vCPUs 数を超えいる。
上記の条件に当てはまる場合は、データベース接続数を減らすことを検討してください。例えば、RDS プロキシなどの接続プールを使用できます。効果的な接続管理とスケーリングのベストプラクティスを学ぶには、ホワイトペーパー[接続管理のための Amazon Aurora MySQL DBA ハンドブック](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)を参照してください。
# io/aurora\$1redo\$1log\$1flush
`io/aurora_redo_log_flush` イベントは、セッションが永続データを Amazon Aurora ストレージに書き込むときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.io-auredologflush.context.supported)
+ [Context](#ams-waits.io-auredologflush.context)
+ [待機時間が増加する原因の可能性](#ams-waits.io-auredologflush.causes)
+ [アクション](#ams-waits.io-auredologflush.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## Context
`io/aurora_redo_log_flush` イベントは Aurora MySQL の書き込み入力/出力 (I/O) オペレーション用です。
**注記**
Aurora MySQL バージョン 3 では、この待機イベントの名前は [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) です。
## 待機時間が増加する原因の可能性
データの永続化のために、コミットはストレージが安定するよう耐久性の高い書き込みを要求とします。データベースがコミットを多くし過ぎると、書き込み I/O オペレーションで待機イベントが発生します、`io/aurora_redo_log_flush` 待機イベント。
次の例では、db.r5.xlarge DB インスタンスクラスを使用して、50,000 レコードが Aurora MySQL DB クラスターに挿入されています。
+ 初期の例では、各セッションは行ごとに 10,000 レコードを挿入しています。デフォルトで、データ操作言語 (DML) コマンドがトランザクション内にない場合、Aurora MySQL は暗黙的なコミットを使用します。オートコミットがオンになっています。これは、各行の挿入に対してコミットがあることを意味します。Performance Insights は、コネクションがほとんどの時間`io/aurora_redo_log_flush` 待機イベントで待っていることを示しています。
![\[Performance Insights 待機イベントの例\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
これは、使用される単純な挿入ステートメントが原因です。
![\[トップ SQL にステートメントを挿入します\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
50,000 レコードは挿入されるまで 3.5 分 かかります。
+ 2 番目の例では、挿入は 1,000 バッチで作成されます。つまり、各接続は 10,000 ではなく 10 のコミットを実行します。Performance Insights は、コネクションがほとんどの時間 `io/aurora_redo_log_flush` 待機イベントで待っていないことを示しています。
![\[影響の少ない Performance Insights 待機イベントの例\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
50,000 レコードが挿入されるまでに 4 秒かかります。
## アクション
待機イベントの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [問題のあるセッションとクエリを特定する](#ams-waits.io-auredologflush.actions.identify-queries)
+ [書き込みオペレーションをグループ化する](#ams-waits.io-auredologflush.actions.action0)
+ [オートコミットをオフにする](#ams-waits.io-auredologflush.actions.action1)
+ [トランザクションの使用](#ams-waits.io-auredologflush.action2)
+ [バッチを使用する](#ams-waits.io-auredologflush.action3)
### 問題のあるセッションとクエリを特定する
DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利な AWS データベースブログ記事は [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
**ボトルネックの原因となっているセッションとクエリを特定するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。
1. **データベース負荷**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
リストの上部にあるクエリは、データベースで最大の負荷を引き起こしています。
### 書き込みオペレーションをグループ化する
次の例は `io/aurora_redo_log_flush` 待機イベントをトリガーしています。(オートコミットがオンになっています。)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
`io/aurora_redo_log_flush` 待機イベントで待機する時間を減らすため、書き込み操作を論理的に 1 つのコミットにグループ化し、ストレージへの永続的な呼び出しを減らします。
### オートコミットをオフにする
次の例に示すように、トランザクション内に存在しない大きな変更を加える前に、オートコミットをオフにします。
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### トランザクションの使用
次の例が示すように、トランサクションを使用することができます。
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### バッチを使用する
次の例が示すように、バッチで変更することもできます。ただし、大きすぎるバッチを使用すると、特にリードレプリカやポイントインタイムリカバリ (PITR) の実行時にパフォーマンスの問題が発生する可能性があります。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
`io/aurora_respond_to_client` イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.respond-to-client.context.supported)
+ [Context](#ams-waits.respond-to-client.context)
+ [待ち時間増加の考えられる原因](#ams-waits.respond-to-client.causes)
+ [アクション](#ams-waits.respond-to-client.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## Context
`io/aurora_respond_to_client` イベントは、スレッドが結果セットをクライアントに返すのを待っているときに発生します。
クエリの処理が完了し、結果はアプリケーションクライアントに返されます。ただし、DB クラスターには十分なネットワーク帯域幅がないため、スレッドは結果セットを返すのを待っています。
## 待ち時間増加の考えられる原因
`io/aurora_respond_to_client` イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
**DB インスタンスクラスがワークロードに対して不十分**
DB クラスターで使用される DB インスタンスクラスには、ワークロードを効率的に処理するために必要なネットワーク帯域幅がありません。
**大きな結果セット**
クエリがより多くの行数を返すため、返される結果セットのサイズが増加しました。結果セットが大きいほど、より多くのネットワーク帯域幅を消費します。
**クライアントへの負荷の増加**
クライアントに CPU プレッシャー、メモリプレッシャー、またはネットワークの飽和が発生する可能性があります。クライアントの負荷が増加すると、Aurora MySQL DB クラスターからのデータの受信が遅れます。
**ネットワークレイテンシーの増加**
Aurora MySQL DB クラスターとクライアント間のネットワークレイテンシーが増加することがあります。ネットワークレイテンシーが大きいほど、クライアントがデータを受信するのに必要な時間が長くなります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.respond-to-client.actions.identify)
+ [DB インスタンスクラスのスケール](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [予期しない結果のワークロードをチェックする](#ams-waits.respond-to-client.actions.workload)
+ [リーダーインスタンスでワークロードを分散する](#ams-waits.respond-to-client.actions.balance)
+ [SQL\$1BUFFER\$1RESULT 修飾子を使用する](#ams-waits.respond-to-client.actions.sql-buffer-result)
### イベントの原因となるセッションとクエリを特定する
Performance Insights を使用して、`io/aurora_respond_to_client` 待機イベントによってブロックされたクエリを表示できます。通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。
### DB インスタンスクラスのスケール
`NetworkReceiveThroughput` や `NetworkTransmitThroughput` などのネットワークスループットに関連する Amazon CloudWatch メトリクスの値の増加を確認します。DB インスタンスクラスのネットワーク帯域幅に達している場合は、DB クラスターを変更することで、DB クラスターで使用される DB インスタンスクラスをスケールできます。より大きなネットワーク帯域幅を持つ DB インスタンスクラスは、データをより効率的にクライアントに返します。
Amazon CloudWatch メトリクスのモニタリングについては、[Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md) を参照してください。DB インスタンスクラスの詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。DB クラスターの変更の詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。
### 予期しない結果のワークロードをチェックする
DB クラスターのワークロードをチェックし、予期しない結果が発生していないことを確認します。例えば、予想よりも多くの行を返すクエリがある可能性があります。この場合、`Innodb_rows_read` などの Performance Insights カウンターメトリクスを使用できます。詳細については、「[Performance Insights カウンターメトリクス](USER_PerfInsights_Counters.md)」を参照してください。
### リーダーインスタンスでワークロードを分散する
Aurora レプリカを使用して、読み取り専用ワークロードを配布できます。Aurora レプリカを追加することで、水平方向にスケールできます。そうすると、ネットワーク帯域幅のスロットリング制限が増加する可能性があります。詳細については、「[Amazon Aurora DB クラスター](Aurora.Overview.md)」を参照してください。
### SQL\$1BUFFER\$1RESULT 修飾子を使用する
`SQL_BUFFER_RESULT` 修飾子 を `SELECT` ステートメントに追加すると、結果がクライアントに返される前にテンポラリテーブルに強制できます。クエリは `io/aurora_respond_to_client` 待機状態になっているため、InnoDB ロックが解放されていない時この修飾子はパフォーマンスの問題に役立ちます。詳細については、MySQL ドキュメントの [SELECT ステートメント](https://dev.mysql.com/doc/refman/5.7/en/select.html)を参照してください。
# io/redo\$1log\$1flush
`io/redo_log_flush` イベントは、セッションが永続データを Amazon Aurora ストレージに書き込むときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.io-redologflush.context.supported)
+ [Context](#ams-waits.io-redologflush.context)
+ [待機時間が増加する原因の可能性](#ams-waits.io-redologflush.causes)
+ [アクション](#ams-waits.io-redologflush.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 3
## Context
`io/redo_log_flush` イベントは Aurora MySQL の書き込み入力/出力 (I/O) オペレーション用です。
**注記**
Aurora MySQL バージョン 2 では、この待機イベントの名前は [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) です。
## 待機時間が増加する原因の可能性
データの永続化のために、コミットはストレージが安定するよう耐久性の高い書き込みを要求とします。データベースがコミットを多くし過ぎると、書き込み I/O オペレーションで待機イベントが発生します、`io/redo_log_flush` 待機イベント。
この待機イベントの動作の例については、「[io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)」を参照してください。
## アクション
待機イベントの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [問題のあるセッションとクエリを特定する](#ams-waits.io-redologflush.actions.identify-queries)
+ [書き込みオペレーションをグループ化する](#ams-waits.io-redologflush.actions.action0)
+ [オートコミットをオフにする](#ams-waits.io-redologflush.actions.action1)
+ [トランザクションの使用](#ams-waits.io-redologflush.action2)
+ [バッチを使用する](#ams-waits.io-redologflush.action3)
### 問題のあるセッションとクエリを特定する
DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利な AWS データベースブログ記事は [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
**ボトルネックの原因となっているセッションとクエリを特定するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。
1. **データベース負荷**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
リストの上部にあるクエリは、データベースで最大の負荷を引き起こしています。
### 書き込みオペレーションをグループ化する
次の例は `io/redo_log_flush` 待機イベントをトリガーしています。(オートコミットがオンになっています。)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
`io/redo_log_flush` 待機イベントで待機する時間を減らすため、書き込み操作を論理的に 1 つのコミットにグループ化し、ストレージへの永続的な呼び出しを減らします。
### オートコミットをオフにする
次の例に示すように、トランザクション内に存在しない大きな変更を加える前に、オートコミットをオフにします。
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### トランザクションの使用
次の例が示すように、トランサクションを使用することができます。
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### バッチを使用する
次の例が示すように、バッチで変更することもできます。ただし、大きすぎるバッチを使用すると、特にリードレプリカやポイントインタイムリカバリ (PITR) の実行時にパフォーマンスの問題が発生する可能性があります。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
`io/socket/sql/client_connection` イベントは、スレッドが新しい接続を処理している最中に発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.client-connection.context.supported)
+ [Context](#ams-waits.client-connection.context)
+ [待ち時間増加の考えられる原因](#ams-waits.client-connection.causes)
+ [アクション](#ams-waits.client-connection.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
イベント`io/socket/sql/client_connection` は、受信する新規クライアント接続を処理するためのスレッド作成で mysqld がビジー状態であることを示します。このシナリオでは、スレッドが割り当てられるのを接続が待っている間、新しいクライアント接続リクエストの対応処理が遅くなります。詳細については、「[MySQLサーバー (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)」を参照してください。
## 待ち時間増加の考えられる原因
この イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
+ アプリケーションから Amazon RDS インスタンスへの新しいユーザー接続が突然増加しています。
+ ネットワーク、CPU、またはメモリがスロットリングされているため、DB インスタンスは新しい接続を処理できません。
## アクション
`io/socket/sql/client_connection` がデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。アイドル状態でないデータベースでは、待機イベントは常に最上位にあります。パフォーマンスが低下したときにのみ動作してください。待機イベントの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [問題のあるセッションとクエリを特定する](#ams-waits.client-connection.actions.identify-queries)
+ [接続管理のベストプラクティス](#ams-waits.client-connection.actions.manage-connections)
+ [リソースがスロットリングされている場合にインスタンスをスケールアップする](#ams-waits.client-connection.upgrade)
+ [上位ホストと上位ユーザーを確認する](#ams-waits.client-connection.top-hosts)
+ [performance\$1schema テーブルのクエリを実行する](#ams-waits.client-connection.perf-schema)
+ [クエリのスレッド状態を確認する](#ams-waits.client-connection.thread-states)
+ [リクエストとクエリを監査する](#ams-waits.client-connection.auditing)
+ [データベース接続をプールする](#ams-waits.client-connection.pooling)
### 問題のあるセッションとクエリを特定する
DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利なデータベースブログ記事は、[Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。
**ボトルネックの原因となっているセッションとクエリを特定するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。
1. **データベース負荷**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
リストの上部にあるクエリは、データベースで最大のロードを引き起こしています。
### 接続管理のベストプラクティス
接続を管理するには、次の戦略を検討してください。
+ 接続プーリングの使用
必要に応じて、接続数を徐々に増やすことができます。詳細については、ホワイトペーパーの [Amazon Aurora MySQL データベース管理者ハンドブック](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)を参照してください。
+ リーダーノードを使用して、読み取り専用トラフィックを再配布します。
詳細については、「[Aurora レプリカ](Aurora.Replication.md#Aurora.Replication.Replicas)」および「[Amazon Aurora エンドポイント接続](Aurora.Overview.Endpoints.md)」を参照してください。
### リソースがスロットリングされている場合にインスタンスをスケールアップする
次のリソースでスロットリングの例を探してください。
+ CPU
Amazon CloudWatch メトリクスで CPU 使用率が高くなるかどうかを確認してください。
+ Network
CloudWatch メトリクス `network receive throughput` および `network transmit throughput` の値の増加を確認します。インスタンスがインスタンスクラスのネットワーク帯域幅制限に達した場合は、RDS インスタンスをより高いインスタンスクラスタイプにスケールアップすることを検討してください。詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
+ 解放可能なメモリ
CloudWatch メトリクス `FreeableMemory` のドロップをチェックします。また、拡張モニタリングをオンにすることを検討してください。詳細については、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。
### 上位ホストと上位ユーザーを確認する
Performance Insights を使用して、上位ホストと上位ユーザーを確認します。詳細については、「[Performance Insights ダッシュボードを使用してメトリクスを分析する](USER_PerfInsights.UsingDashboard.md)」を参照してください。
### performance\$1schema テーブルのクエリを実行する
現在の接続数と合計接続数の正確な数を取得するには、`performance_schema` テーブルをクエリします。この手法では、多数の接続の作成を担当する出典ユーザーまたはホストを特定します。例えば、次の通り `performance_schema` テーブルをクエリします。
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### クエリのスレッド状態を確認する
パフォーマンスの問題が継続する場合は、クエリのスレッド状態を確認してください。`mysql` クライアントで、次のコマンドを実行します。
```
show processlist;
```
### リクエストとクエリを監査する
ユーザーアカウントからのリクエストとクエリの性質を確認するには、AuroraAurora MySQL アドバンスト監査を使用します。監査を有効にする方法については、[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md) を参照してください。
### データベース接続をプールする
接続管理に Amazon RDS プロキシを使用することを検討してください。RDS プロキシーを使用すると、アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケール能力を向上させることができます。RDS Proxy は、アプリケーション接続を維持しながらスタンバイ DB インスタンスに自動的に接続することで、データベースの障害に対するアプリケーションの耐障害性を高めます。詳細については、「[Amazon RDS Proxy for Aurora](rds-proxy.md)」を参照してください。
# io/table/sql/handler
`io/table/sql/handler` イベントは、作業がストレージエンジンに委任されたときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.waitio.context.supported)
+ [Context](#ams-waits.waitio.context)
+ [待機時間が増加する原因の可能性](#ams-waits.waitio.causes)
+ [アクション](#ams-waits.waitio.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
イベント `io/table` は、テーブルへのアクセスを待っていることを示します。このイベントは、データがバッファプールにキャッシュされているか、ディスク上でアクセスされているかにかかわらず、発生します。`io/table/sql/handler` イベントは、ワークロードアクティビティの増加を示します。
*ハンドラー*は、特定の種類のデータに特化したルーチンか、特定の特別なタスクに焦点を当てたルーチンです。例えば、イベントハンドラーは、オペレーティングシステムまたはユーザーインターフェイスからイベントとシグナルを受信してダイジェストします。メモリハンドラーは、メモリに関連するタスクを実行します。ファイル入力ハンドラは、ファイル入力を受け取り、コンテキストに応じてデータに対して特別なタスクを実行する関数です。
`performance_schema.events_waits_current` などの ビューは、実際の待機がロックなどのネストされた待機イベントである場合に `io/table/sql/handler` をよく表示します。実際の待機が `io/table/sql/handler` ではない場合、Performance Insights はネストされた待機イベントをレポートします。Performance Insights が `io/table/sql/handler` をレポートする場合、非表示のネストされた待機イベントではなく I/O リクエストの InnoDB 処理を表します。詳細については、*MySQL リファレンスマニュアル*の[「パフォーマンススキーマの原子および分子イベント」](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)を参照してください。
`io/table/sql/handler` イベントは多くの場合、`io/aurora_redo_log_flush` のような I/O 待機を伴う上位の待機イベントに表示されます。
## 待機時間が増加する原因の可能性
Performance Insights で、`io/table/sql/handler` イベントの急増はワークロードアクティビティの増加を示します。アクティビティの増加は、I/O が増加することを意味します。
Performance Insights はネストイベント ID をフィルタリングし、基盤となるネストされたイベントがロック待機である場合、`io/table/sql/handler` 待機をレポートします。例えば、根本原因イベントが [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) である場合、Performance Insights は `io/table/sql/handler` ではなく 上位待機イベントにこの待機を表示します。
`performance_schema.events_waits_current` などのビューは、実際の待機がロックなどのネストされた待機イベントである場合によく`io/table/sql/handler` の待機を表示します。実際の待ち時間が `io/table/sql/handler` と異なる場合、Performance Insights はネストされた待機を検索し、`io/table/sql/handler` の代わりに実際の待機を報告します。Performance Insights が `io/table/sql/handler` をレポートする場合、実際の待機は非表示のネストされた待機イベントではなく、`io/table/sql/handler` になります。詳細については、[「MySQL 5.7 リファレンスマニュアル」](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)の*「パフォーマンススキーマのアトムおよび分子イベント」*を参照してください。
## アクション
待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。データベースがアクティブな場合、待機イベントは常に最上位になります。パフォーマンスが低下したときにのみ動作してください。
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.waitio.actions.identify)
+ [Performance Insights カウンター指標との相関関係をチェックする](#ams-waits.waitio.actions.filters)
+ [他の相関待ちイベントがないかチェックする](#ams-waits.waitio.actions.maintenance)
### イベントの原因となるセッションとクエリを特定する
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### Performance Insights カウンター指標との相関関係をチェックする
`Innodb_rows_changed` などの Performance Insights カウンターメトリクスをチェックします。カウンタメトリックが `io/table/sql/handler` と相関している場合、以下のステップを実行します。
1. Performance Insights で、`io/table/sql/handler` トップ待機イベントの原因になっている SQL ステートメントを探します。可能であれば、このステートメントを最適化して、返される行数を減らします。
1. `schema_table_statistics` と `x$schema_table_statistics` ビューからトップテーブルを取得します。これらのビューには、テーブルごとに費やされた時間が表示されます。詳細については、*MySQL リファレンスマニュアル*の [schema\$1table\$1statistics と x\$1schema\$1table\$1statistics ビュー](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) を参照してください。
デフォルトでは、行は合計待機時間の降順でソートされます。競合が最も多いテーブルが初期に表示されます。出力は、読み取り、書き込み、フェッチ、挿入、更新、または削除に時間を費やしているかどうかを示します。
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### 他の相関待ちイベントがないかチェックする
`synch/sxlock/innodb/btr_search_latch` と `io/table/sql/handler` が共に DB ロードの異常に最も貢献している場合、`innodb_adaptive_hash_index` 可変がオンになっているかチェックします。もしそうであれば、`innodb_adaptive_hash_index_parts` パラメータ値を増やすことを検討します。
Adaptive Hash インデックスがオフになっている場合、オンにすることを検討します。MySQL adaptive Hash インデックスの詳細については、以下のリソースを参照してください。
+ Percona Web サイトの記事「[InnoDB の Adaptive Hash Index は私のワークロードに適していますか？](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload)」
+ *MySQL リファレンスマニュアル*の[アダプティブハッシュインデックス](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html)
+ Percona ウェブサイトの [MySQL InnoDB での競合: セマフォセクションからの有用な情報](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/)の記事
**注記**
Adaptive Hash インデックスは Aurora Reader DB インスタンスではサポートされていません。
`synch/sxlock/innodb/btr_search_latch` と `io/table/sql/handler` が支配的な場合、リーダーインスタンスのパフォーマンスが低下することがあります。その場合は、ワークロードをライター DB インスタンスに一時的にリダイレクトし、Adaptive Hash インデックスをオンにすることを検討してください。
# synch/cond/innodb/row\$1lock\$1wait
`synch/cond/innodb/row_lock_wait` イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、MySQL ドキュメントの「[InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html)」を参照してください。
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 3
## 待機時間が増加する原因の可能性
複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。
## アクション
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [この待機イベントを担当する SQL 文を見つけて応答します。](#ams-waits.row-lock-wait.actions.id)
+ [ブロッキングセッションを見つけて対応する](#ams-waits.row-lock-wait.actions.blocker)
### この待機イベントを担当する SQL 文を見つけて応答します。
Performance Insights を使用して、この待機イベントの原因になっている SQL ステートメントを特定します。以下の戦略を検討して下さい。
+ 行のロックが永続的な問題である場合は、オプティミスティックロックを使用するようにアプリケーションを書き直すことを検討してください。
+ 複数行のステートメントの使用。
+ ワークロードを異なるデータベースオブジェクトに分散します。パーティショニングによって、これを行うことができます。
+ `innodb_lock_wait_timeout` パラメータの値をチェックしてください。これは、タイムアウトエラーを生成する前にトランザクションが待機する時間を制御します。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### ブロッキングセッションを見つけて対応する
ブロッキングセッションがアイドルかアクティブかを確認します。また、セッションがアプリケーションからかのものか、またはアクティブユーザーからのものであるかを調べます。
ロックを保持しているセッションを識別するには、`SHOW ENGINE INNODB STATUS` を実行します。次の例は サンプル出力を示しています。
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
または、次のクエリを使用して、現在のロックの詳細を抽出することもできます。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、MySQL ドキュメントの「[Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html)」を参照してください。
# synch/cond/innodb/row\$1lock\$1wait\$1cond
`synch/cond/innodb/row_lock_wait_cond` イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、MySQL ドキュメントの「[InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)」を参照してください。
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## 待機時間が増加する原因の可能性
複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。
## アクション
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [この待機イベントを担当する SQL 文を見つけて応答します。](#ams-waits.row-lock-wait-cond.actions.id)
+ [ブロッキングセッションを見つけて対応する](#ams-waits.row-lock-wait-cond.actions.blocker)
### この待機イベントを担当する SQL 文を見つけて応答します。
Performance Insights を使用して、この待機イベントの原因になっている SQL ステートメントを特定します。以下の戦略を検討して下さい。
+ 行のロックが永続的な問題である場合は、オプティミスティックロックを使用するようにアプリケーションを書き直すことを検討してください。
+ 複数行のステートメントの使用。
+ ワークロードを異なるデータベースオブジェクトに分散します。パーティショニングによって、これを行うことができます。
+ `innodb_lock_wait_timeout` パラメータの値をチェックしてください。これは、タイムアウトエラーを生成する前にトランザクションが待機する時間を制御します。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### ブロッキングセッションを見つけて対応する
ブロッキングセッションがアイドルかアクティブかを確認します。また、セッションがアプリケーションからかのものか、またはアクティブユーザーからのものであるかを調べます。
ロックを保持しているセッションを識別するには、`SHOW ENGINE INNODB STATUS` を実行します。次の例は サンプル出力を示しています。
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
または、次のクエリを使用して、現在のロックの詳細を抽出することもできます。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、MySQL ドキュメントの「[Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)」を参照してください。
# synch/cond/sql/MDL\$1context::COND\$1wait\$1status
`synch/cond/sql/MDL_context::COND_wait_status` イベントは、テーブルメタデータロックに待機中のスレッドがあるときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.cond-wait-status.context.supported)
+ [Context](#ams-waits.cond-wait-status.context)
+ [待ち時間増加の考えられる原因](#ams-waits.cond-wait-status.causes)
+ [アクション](#ams-waits.cond-wait-status.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
イベント `synch/cond/sql/MDL_context::COND_wait_status` は、テーブルメタデータロックを待機中のスレッドがあることを示します。場合によっては、あるセッションがテーブルのメタデータロックを保持し、別のセッションが同じテーブルで同じロックを取得しようとする場合があります。このような場合、2 番目のセッションは `synch/cond/sql/MDL_context::COND_wait_status` 待機イベントで待機します。
MySQL は、メタデータロックを使用して、データベースオブジェクトへの同時アクセスを管理し、データの整合性を確保します。メタデータのロックは、`get_lock` 関数で取得したスケジュールされたイベント、テーブルスペース、ユーザーロックテーブル、および ストアドプログラムに適用されます。ストアドプログラムには、プロシージャ、関数、トリガーが含まれます。詳細については、MySQL ドキュメントの[メタデータロック](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html)を参照してください。
MySQL プロセスリストは、このセッションを状態 `waiting for metadata lock` で表示されます。Performance Insights では、`Performance_schema` がオンになっている場合、イベント `synch/cond/sql/MDL_context::COND_wait_status` が表示されます。
メタデータロックで待っているクエリのデフォルトタイムアウトは `lock_wait_timeout` パラメータ値に基づきます。デフォルトは 31,536,000 秒 (365 日) です。
さまざまな InnoDB ロックと競合を引き起こす可能性のあるロックの種類の詳細については、MySQL ドキュメントの [InnoDB ロック](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)を参照してください。
## 待ち時間増加の考えられる原因
`synch/cond/sql/MDL_context::COND_wait_status` イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
**実行時間が長いトランザクション**
1 つ以上のトランザクションが大量のデータを変更し、非常に長い間テーブルのロックを保持しています。
**Idle トランザクション**
1 つ以上のトランザクションは、コミットまたはロールバックされることなく、長い間開いたままです。
**大きなテーブルの DDL ステートメント**
1 つ以上のデータ定義ステートメント (DDL) ステートメント。`ALTER TABLE`コマンドは、非常に大きなテーブルで実行されました。
**明示的なテーブルロック**
テーブルには、タイムリーに解放されない明示的なロックがあります。例えば、アプリケーションが実行されているとします。`LOCK TABLE`不適切にステートメント。
## アクション
待機イベントの原因と Aurora MySQL DB クラスターのバージョンに応じて、さまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.cond-wait-status.actions.identify)
+ [過去のイベントをチェックする](#ams-waits.cond-wait-status.actions.past-events)
+ [Aurora MySQL バージョン 2 でクエリを実行する](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [ブロッキングセッションに応答する](#ams-waits.cond-wait-status.actions.blocker)
### イベントの原因となるセッションとクエリを特定する
Performance Insights を使用して、`synch/cond/sql/MDL_context::COND_wait_status` 待機イベントによってブロックされたクエリを表示できます。ただし、ブロッキングセッションを特定するには、からメタデータテーブルをクエリします。`performance_schema`そして`information_schema`DB クラスター上にあります。
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。この DB インスタンスに Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。
### 過去のイベントをチェックする
この待機イベントについてのインサイトを取得して、過去のイベントが発生していないかどうかをチェックできます。そのためには、以下のアクションを実行します。
+ データ操作言語 (DML) と DDL のスループットとレイテンシーを調べて、ワークロードに変更があったかどうかをチェックします。
Performance Insights を使用して、問題発生時にこのイベントで待っているクエリを検索できます。また、発行時に実行されたクエリのダイジェストを表示することもできます。
+ DB クラスターの監査ログまたは一般ログがオンになっている場合、待機中のトランザクションに含まれるオブジェクト (schema.table) で実行されるすべてのクエリをチェックできます。また、トランザクションの前に実行が完了したクエリをチェックすることもできます。
過去のイベントのトラブルシューティングに使用できる情報は限られています。これらのチェックを実行しても、どのオブジェクトが情報を待っているのかは示されません。ただし、イベント時にロードが大きいテーブルや、発行時に競合の原因となる頻繁に操作される一連の行を特定できます。この情報を使用して、テスト環境で問題を再現し、その原因に関するインサイトを使用できます。
### Aurora MySQL バージョン 2 でクエリを実行する
Aurora MySQL バージョン 2 の場合、`performance_schema` テーブルないし `sys` ビューに対してクエリを実行して、ブロックされたセッションを直接識別できます。。例は、ブロックしているクエリとセッションを識別するため、テーブルにクエリを実行する方法を示しています。
次のプロセスリストの出力では、接続 ID `89` がメタデータロックを待っていて、`TRUNCATE TABLE` コマンドを実行しています。`performance_schema` テーブルないし `sys` スキーマビューのクエリの場合、出力が表示するブロッキングセッションは `76` です。
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
次に、`performance_schema` テーブルないし `sys` スキーマビューのクエリはブロッキングセッションが `76` であることを示します。
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### ブロッキングセッションに応答する
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、MySQL ドキュメントの[InnoDB トランザクションの使用と情報のロック](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)を参照してください。
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
`synch/mutex/innodb/aurora_lock_thread_slot_futex` イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、[MySQL リファレンス](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)の *InnoDB ロック*を参照してください。
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## 待機時間が増加する原因の可能性
複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。
## アクション
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [この待機イベントを担当する SQL 文を見つけて応答します。](#ams-waits.waitsynch.actions.id)
+ [ブロッキングセッションを見つけて対応する](#ams-waits.waitsynch.actions.blocker)
### この待機イベントを担当する SQL 文を見つけて応答します。
Performance Insights を使用して、この待機イベントの原因になっている SQL ステートメントを特定します。以下の戦略を検討して下さい。
+ 行のロックが永続的な問題である場合は、オプティミスティックロックを使用するようにアプリケーションを書き直すことを検討してください。
+ 複数行のステートメントの使用。
+ ワークロードを異なるデータベースオブジェクトに分散します。パーティショニングによって、これを行うことができます。
+ `innodb_lock_wait_timeout` パラメータの値をチェックしてください。これは、タイムアウトエラーを生成する前にトランザクションが待機する時間を制御します。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### ブロッキングセッションを見つけて対応する
ブロッキングセッションがアイドルかアクティブかを確認します。また、セッションがアプリケーションからかのものか、またはアクティブユーザーからのものであるかを調べます。
ロックを保持しているセッションを識別するには、`SHOW ENGINE INNODB STATUS` を実行します。次の例は サンプル出力を示しています。
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
または、次のクエリを使用して、現在のロックの詳細を抽出することもできます。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、*MySQL リファレンスマニュアル*の [InnoDB トランザクションの使用とロック情報](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)を参照してください。
# synch/mutex/innodb/buf\$1pool\$1mutex
`synch/mutex/innodb/buf_pool_mutex` イベントは、スレッドがメモリ内のページにアクセスするために InnoDB バッファプールのロックを取得したときに発生します。
**Topics**
+ [関連するエンジンバージョン](#ams-waits.bufpoolmutex.context.supported)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.bufpoolmutex.causes)
+ [アクション](#ams-waits.bufpoolmutex.actions)
## 関連するエンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## Context
`buf_pool` ミューテックスは、バッファプールの制御データ構造を保護する単一のミューテックスです。
詳細については、MySQL ドキュメントの[パフォーマンススキーマを使用した InnoDB Mutex 待機をモニタリングする](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)を参照してください。
## 待ち時間増加の考えられる原因
これは、ワークロード固有の待機イベントです。`synch/mutex/innodb/buf_pool_mutex` がトップ待機イベント内に出現する一般的な原因は、次のような場合が含まれます。
+ バッファープールのサイズが、ワーキングデータセットを保持するのに十分な大きさではない。
+ ワークロードが、データベース内の特定のテーブルの特定のページに固有であり、バッファプール内に競合が発生ている。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.bufpoolmutex.actions.identify)
+ [Performance Insights の使用](#ams-waits.bufpoolmutex.actions.action1)
+ [Aurora レプリカの作成](#ams-waits.bufpoolmutex.actions.action2)
+ [バッファープールサイズの検査](#ams-waits.bufpoolmutex.actions.action3)
+ [グローバルステータス履歴をモニタリングする](#ams-waits.bufpoolmutex.actions.action4)
### イベントの原因となるセッションとクエリを特定する
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**AWSマネジメントコンソールの トップ SQL チャートを表示するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. **データベースロード**グラフの下で、**トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### Performance Insights の使用
このイベントはワークロードに関連しています。Performance Insights を使用して、以下を実行できます。
+ 待機イベントがスタートされたタイミングと、その時点でアプリケーションログまたは関連出典からのワークロードに変化があったかどうかを特定します。
+ この待機イベントの原因になっている SQL ステートメントを特定します。クエリの実行プランを調べて、これらのクエリが最適化され、適切なインデックスが使用されていることを確認します。
待機イベントの原因となる上位クエリが同じデータベースオブジェクトまたはテーブルに関連付けられている場合は、そのオブジェクトまたはテーブルをパーティション化することを検討してください。
### Aurora レプリカの作成
Aurora レプリカを作成して、読み取り専用トラフィックを処理できます。Aurora オートスケーリングを使用して、読み取りトラフィックのサージを処理することもできます。Aurora レプリカでスケジュールされた読み取り専用タスクと論理的なバックアップを実行してください。
詳細については、「[Aurora レプリカでの Amazon Aurora Auto Scaling](Aurora.Integrating.AutoScaling.md)」を参照してください。
### バッファープールサイズの検査
メトリクス `innodb_buffer_pool_wait_free` を確認して、バッファ・プール・サイズがワークロードに十分かどうかをチェックします。このメトリクスの値が高く継続的に増加している場合は、バッファ・プールのサイズがワークロードを処理するのに十分でないことを示します。`innodb_buffer_pool_size` が適切に設定されている場合、`innodb_buffer_pool_wait_free` の値は小さくなります。詳細については、MySQL ドキュメントの[Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free)を参照してください。
DB インスタンス上に、セッションバッファとオペレーティングシステムのタスクに十分なメモリがある場合は、バッファプールサイズを増やします。そうでない場合は、DB インスタンスを大きな DB インスタンスクラスに変更して、バッファプールに割り当てられる追加のメモリを取得します。
**注記**
Aurora MySQL は、構成された `innodb_buffer_pool_size` に基づいて`innodb_buffer_pool_instances` の値を自動的に調整します
### グローバルステータス履歴をモニタリングする
ステータス可変の変更率をモニタリングすることで、DB インスタンスのロックまたはメモリの問題を検出できます。グローバルステータス履歴 (GoSH) がまだオンになっていない場合は、オンにします。GoSH の詳細については、[グローバルステータス履歴の管理](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)を参照してください。
カスタムの Amazon CloudWatch メトリクスを作成して、ステータス可変をモニタリングすることもできます。詳細については、[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を参照してください。
# synch/mutex/innodb/fil\$1system\$1mutex
`synch/mutex/innodb/fil_system_mutex` イベントは、セッションがテーブルスペースのメモリキャッシュへのアクセスを待っているときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Context](#ams-waits.innodb-fil-system-mutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.innodb-fil-system-mutex.causes)
+ [アクション](#ams-waits.innodb-fil-system-mutex.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
InnoDB はテーブルスペースを使用して、テーブルとログファイルのストレージ領域を管理します。*テーブルスペースのメモリキャッシュ*は、テーブルスペースに関する情報を保持するグローバル・メモリ構造です。MySQL は `synch/mutex/innodb/fil_system_mutex` 待機を使用して、テーブルスペースのメモリー・キャッシュへの同時アクセスを制御します。
イベント `synch/mutex/innodb/fil_system_mutex` は、テーブルスペースメモリーキャッシュにある情報を、同じテーブルスペースに対して取得または操作しないといけないオペレーションが現在複数存在することを示します。
## 待ち時間増加の考えられる原因
`synch/mutex/innodb/fil_system_mutex` イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
+ 同じテーブル内のデータを更新または削除する、同時データ操作言語 (DML) オペレーションの増加。
+ このテーブルのテーブルスペースは非常に大きく、多くのデータページがあります。
+ これらのデータページの塗りつぶし係数は低いです。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [オフピーク時に大きなテーブルを再編成する](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### イベントの原因となるセッションとクエリを特定する
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。この DB インスタンスに Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
どのクエリが多数の`synch/mutex/innodb/fil_system_mutex` 待機原因になっているかを調べる別の方法は、、以下の例のように `performance_schema` をチェックする方法です。
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### オフピーク時に大きなテーブルを再編成する
本番時間外のメンテナンスウィンドウで、多数の `synch/mutex/innodb/fil_system_mutex` 待機イベントの出典として識別するラージテーブルを再編成する。これにより、テーブルへのクイックアクセスが必修な際に、内部テーブルスペースマップのクリーンアップが行われないようにします。テーブルの再編成については、*MySQL リファレンス*の [TABLE ステートメントの最適化](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html)を参照してください。
# synch/mutex/innodb/trx\$1sys\$1mutex
`synch/mutex/innodb/trx_sys_mutex` イベントは、大量のトランザクションで高いデータベースアクティビティがある場合に発生します。
**Topics**
+ [関連するエンジンバージョン](#ams-waits.trxsysmutex.context.supported)
+ [Context](#ams-waits.trxsysmutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.trxsysmutex.causes)
+ [アクション](#ams-waits.trxsysmutex.actions)
## 関連するエンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3
## Context
内部的には、InnoDB データベースエンジンは、繰り返し可能な読み取り分離レベルとスナップショットを使用して、読み取りの整合性を提供します。これにより、スナップショットが作成された時点でのデータベースのポイントインタイムビューが表示されます。
InnoDB では、コミットされているかどうかにかかわらず、すべての変更が到着するとすぐにデータベースに適用されます。このアプローチは、マルチバージョン同時実行制御 (MVCC) を使用しないと、データベースに接続されているすべてのユーザーに、すべての変更と最新の行が表示されることを意味します。したがって、InnoDB ではロールバックする内容を理解するために、変更を追跡する方法が必要に応じて必要です。
これを行うために、InnoDB はトランザクションシステム (`trx_sys`) を使用してスナップショットを追跡します。トランザクションシステムは、以下を実行します。
+ 元に戻すログの各行に対するトランザクション ID を追跡します。
+ `ReadView` 呼ばれる内部 InnoDB 構造体を使用すると、スナップショットで表示されるトランザクション ID の特定を容易に行えます。
## 待ち時間増加の考えられる原因
一貫性のある制御されたトランザクション ID 処理 (作成、読み取り、更新、および削除) を必要とする全てのデータベースオペレーションは、`trx_sys` からミューテックスに呼び出しを行います。
これらの呼び出しは、次の 3 つの関数内で発生します。
+ `trx_sys_mutex_enter` － ミューテックスを作成する。
+ `trx_sys_mutex_exit` － ミューテックスを解放する。
+ `trx_sys_mutex_own` － ミューテックスが所有されているかどうかをテストする。
InnoDB パフォーマンススキーマインストルメンテーションは、すべての `trx_sys` ミューテックスの呼び出しを追跡します。追跡には管理が含まれますが、これらに限定されません。`trx_sys`データベースの起動時またはシャットダウン、ロールバック操作、クリーンアップの取り消し、行の読み取りアクセス、およびバッファプールのロード。トランザクション数が多く、データベースアクティビティが高い場合、`synch/mutex/innodb/trx_sys_mutex` は上位の待機イベント中に現れます。
詳細については、MySQL ドキュメントの[パフォーマンススキーマを使用した InnoDB Mutex 待機をモニタリングする](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)を参照してください。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.trxsysmutex.actions.identify)
+ [他の待機イベントを検査する](#ams-waits.trxsysmutex.actions.action1)
### イベントの原因となるセッションとクエリを特定する
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを見てください。これらのイベントを減らすためにデータベースとアプリケーションを最適化できるかどうかを調べます。
**AWS マネジメントコンソール で上位 SQL チャートを表示するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. **データベースロード**グラフで、**上位の SQL**を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### 他の待機イベントを検査する
`synch/mutex/innodb/trx_sys_mutex` 待機イベントに関連する他の待機イベントを調べます。これにより、ワークロードの性質に関する詳細情報が提供されます。トランザクションの数が多いとスループットが低下する可能性がありますが、ワークロードによってはこれが必要な場合もあります。
トランザクションを最適化する方法の詳細については、MySQL ドキュメントの [InnoDB トランザクション管理の最適化](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)を参照してください。
# synch/sxlock/innodb/hash\$1table\$1locks
`synch/sxlock/innodb/hash_table_locks` イベントは、バッファプール内に見つからないページをストレージから読み込む必要があるときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Context](#ams-waits.sx-lock-hash-table-locks.context)
+ [待ち時間増加の考えられる原因](#ams-waits.sx-lock-hash-table-locks.causes)
+ [アクション](#ams-waits.sx-lock-hash-table-locks.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のバージョンでサポートされています:
+ Aurora MySQL バージョン 2 および 3
## Context
イベント `synch/sxlock/innodb/hash_table_locks` は、ワークロードがバッファプールに保存されていないデータに頻繁にアクセスしていることを示します。この待機イベントは、バッファプールからの新しいページの追加と古いデータの削除に関連付けられます。バッファプールに格納されたデータは、古いデータおよび新しいデータをキャッシュする必要があります。そのため、古いページは削除され、新しいページのキャッシュが可能になります。MySQL は、バッファプールからページを削除するために、最近一番使用されていない (LRU) アルゴリズムを使用します。ワークロードは、バッファプールにロードされていないデータ、またはバッファプールから削除されたデータにアクセスしようとしています。
この待機イベントは、ワークロードがディスク上のファイル内のデータにアクセスする必要がある場合、またはブロックがバッファプールの LRU リストから解放または追加されたときに発生します。これらのオペレーションは、共有除外ロック (SX-Lock) の取得を待ちます。この SX-Lock は、*ハッシュテーブル*上での同期化に使われます。これは、バッファプールのアクセスパフォーマンスを向上させるために設計されたメモリ内のテーブルです。
詳細については、MySQL ドキュメントの[バッファプール](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html)を参照してください。
## 待ち時間増加の考えられる原因
`synch/sxlock/innodb/hash_table_locks` 待機イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
**サイズの小さいバッファープール**
バッファプールのサイズが小さすぎて、頻繁にアクセスされるすべてのページをメモリ内に保持できません。
**ヘビーワークロード**
ワークロードによって、バッファキャッシュで頻繁にエビクションとデータページがリロードされます。
**ページの読み取り中にエラーが発生しました**
バッファープール内のページの読み取り中にエラーが発生しました。これは、データの破損を示している可能性があります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [バッファプールのサイズを増やす](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [データアクセスパターンの改善](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [フルテーブルスキャンの削減または回避](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [エラーログでページの破損を確認します。](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### バッファプールのサイズを増やす
バッファプールがワークロードに合わせて適切なサイズになっていることを確認します。そのためには、バッファプールのキャッシュヒット率を確認できます。通常、値が 95% を下回った場合は、バッファプールのサイズを大きくすることを検討してください。バッファプールが大きいほど、頻繁にアクセスされるページをメモリ内に長く保持できます。バッファプールのサイズを増やすには、`innodb_buffer_pool_size` パラメータの値を変更します。このパラメータのデフォルト値は、DB インスタンスクラスのサイズに基づいています。詳細については、[Amazon Aurora MySQL データベース設定のベストプラクティス](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)を参照してください。
### データアクセスパターンの改善
この待機の影響を受けるクエリとその実行プランを確認します。データアクセスパターンの改善を検討してください。例えば[mysqli\$1result:: fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php) を使用している場合には、配列のフェッチサイズを大きくしてみるなどが可能です。
Performance Insights を使用して、`synch/sxlock/innodb/hash_table_locks` 待機イベントの原因となっている可能性のあるクエリとセッションを表示できます。
**高ロードの原因となる SQL クエリを検索するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、[**Performance Insights**] を選択します。
1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。
1. **データベースロード**で、**待機でスライス**を選択します。
1. ページの下部で **トップ SQL** を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)を参照してください。
### フルテーブルスキャンの削減または回避
ワークロードをモニタリングして、フルテーブルスキャンが実行されているかどうかを確認し、実行している場合はそれを減らすか回避します。例えば、`Handler_read_rnd_next` のようなステータス可変をモニタリングできます。詳細については、MySQL ドキュメントの[サーバーステータス可変](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next)を参照してください。
### エラーログでページの破損を確認します。
mysql-error.log をチェックして、問題の発生時に検出された破損関連のメッセージを確認できます。問題を解決するために作業できるメッセージは、エラーログに記録されます。破損として報告されたオブジェクトを再作成する必要がある場合があります。
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
`synch/mutex/innodb/temp_pool_manager_mutex` 待機イベントは、セッションがセッション一時テーブルスペースのプールを管理するためのミューテックスの取得を待機しているときに発生します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.io-temppoolmanager.context.supported)
+ [Context](#ams-waits.io-temppoolmanager.context)
+ [待機時間が増加する原因の可能性](#ams-waits.io-temppoolmanager.causes)
+ [アクション](#ams-waits.io-temppoolmanager.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 3
## Context
Aurora MySQL バージョン 3.x 以降では、`temp_pool_manager_mutex` を使用して、一時テーブルスペースプールに同時にアクセスする複数のセッションを制御します。Aurora MySQL は、永続データ用に Aurora クラスターボリュームを介してストレージを管理し、一時ファイル用にローカルストレージを管理します。セッションが Aurora クラスターボリュームに一時テーブルを作成する場合、一時テーブルスペースが必要です。
セッションが初めて一時テーブルスペースをリクエストすると、MySQL は共有プールからセッション一時テーブルスペースを割り当てます。セッションには、次のテーブルタイプで一度に最大 2 つの一時テーブルスペースを保持できます。
+ ユーザーが作成した一時テーブル
+ オプティマイザが生成した内部一時テーブル
デフォルトの `TempTable` エンジンは、次のオーバーフローメカニズムを使用して一時テーブルを処理します。
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 制限までテーブルを RAM に保存します。
+ RAM がいっぱいになると、ローカルストレージのメモリマップファイルに移動します。
+ メモリマップされたファイルが [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 制限に達すると、共有クラスターボリュームを使用します。
一時テーブルが RAM とローカルストレージの両方の制限を超えると、MySQL はディスク上のテーブルスペースを使用して一時テーブルを管理します。
セッションでディスク上の一時テーブルが必要な場合、MySQL は次のようになります。
+ プールで使用可能な `INACTIVE` テーブルスペースを探して再利用します。
+ `INACTIVE` スペースが存在しない場合は、10 個の新しいテーブルスペースを作成します。
セッションが切断されると、MySQL は次の操作を行います。
+ セッションの一時テーブルスペースを切り捨てます。
+ 再利用するためにプールでそれらを INACTIVE としてマークします。
+ サーバーの再起動まで現在のプールサイズを維持します。
+ 再起動後、デフォルトのプールサイズ (10 テーブルスペース) に戻ります。
## 待機時間が増加する原因の可能性
この待機イベントの原因となる一般的な状況。
+ クラスターボリュームに内部一時テーブルを作成する同時セッション。
+ クラスターボリュームにユーザー一時テーブルを作成する同時セッション。
+ アクティブなテーブルスペースを使用したセッションの突然の終了。
+ 書き込み負荷の高いワークロード中のテーブルスペースプールの拡張。
+ アクセスする同時クエリ `INFORMATION_SCHEMA.`
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [一時テーブルの使用状況のモニタリングと最適化](#ams-waits.io-temppoolmanager.actions.monitor)
+ [INFORMATION\$1SCHEMA を使用してクエリを確認する](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [innodb\$1sync\$1array\$1size パラメータを増やす](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [接続プールを実装する](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### 一時テーブルの使用状況のモニタリングと最適化
一時テーブルの使用状況をモニタリングして最適化するには、次のいずれかの方法を使用します。
+ Performance Insights の `Created_tmp_disk_tables` カウンターをチェックして、Aurora クラスター全体でディスク上の一時テーブルの作成を追跡します。
+ データベースでこのコマンドを実行して、一時テーブルの作成を直接モニタリングします。`mysql> show status like '%created_tmp_disk%'`。
**注記**
一時テーブルの動作は、Aurora MySQL リーダーノードとライターノードで異なります。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。
一時テーブルを作成するクエリを特定したら、以下の最適化ステップを実行します。
+ `EXPLAIN` を使用してクエリ実行プランを調べ、一時テーブルが作成される場所と理由を特定します。
+ クエリを変更して、可能な場合は一時テーブルの使用量を減らします。
クエリの最適化だけではパフォーマンスの問題を解決できない場合は、以下の設定パラメータの調整を検討してください。
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) – 一時テーブルの最大 RAM 使用量を制御します。
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) – メモリマップされたファイルストレージの制限を設定します。
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size) – `aurora_tmptable_enable_per_table_limit` が有効になっている場合に適用されます (デフォルトでは無効)。
**重要**
特定のクエリ条件では、設定に関係なく、常にディスク上の一時テーブルが必要になることに注意してください。`TempTable` ストレージエンジンの詳細については、「[Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)」を参照してください。
### INFORMATION\$1SCHEMA を使用してクエリを確認する
`INFORMATION_SCHEMA` テーブルをクエリすると、MySQL はクラスターボリュームに InnoDB 一時テーブルを作成します。各セッションには、これらのテーブルの一時テーブルスペースが必要です。これにより、同時アクセスが多い場合にパフォーマンスの問題が発生する可能性があります。
パフォーマンスを向上させるには。
+ 可能な限り `INFORMATION_SCHEMA` の代わりに `PERFORMANCE_SCHEMA` を使用します。
+ `INFORMATION_SCHEMA` を使用する必要がある場合は、これらのクエリを実行する頻度を減らします。
### innodb\$1sync\$1array\$1size パラメータを増やす
`innodb_sync_array_size` パラメータは、MySQL のミューテックス/ロック待機配列のサイズを制御します。`1` のデフォルト値は一般的なワークロードで機能しますが、これを増やすと、同時実行数が多いときにスレッドの競合を減らすことができます。
ワークロードで待機スレッドの数が増えると表示される場合。
+ ワークロード内の待機中のスレッドの数をモニタリングします。
+ スレッド調整構造を分割し、競合を減らすには、`innodb_sync_array_size` をインスタンスの vCPU 数以上に設定します。
**注記**
RDS インスタンスで使用可能な vCPU の数を確認するには、[Amazon RDS インスタンスタイプ](https://aws.amazon.com/rds/instance-types/)の vCPU 仕様を参照してください。
### 接続プールを実装する
MySQL は、一時テーブルを作成する各セッションに専用のテーブルスペースを割り当てます。このテーブルスペースは、データベース接続が終了するまでアクティブのままです。リソースをより効率的に管理するには。
+ 接続プーリングを実装して、アクティブな一時テーブルスペースの数を制限します。
+ オペレーションごとに新しい接続を作成する代わりに、既存の接続を再利用します。
# スレッド状態を使用した Aurora MySQL のチューニング
次の表は Aurora MySQL の最も一般的なスレッド状態をまとめたものです。
| 一般的なスレッド状態 | 説明 |
| --- | --- |
| [ソートインデックスの作成](ams-states.sort-index.md) | このスレッド状態は、データをソートするために内部テンポラリテーブルを使用する必要がある `SELECT` ステートメントを、スレッドが処理中であることを示します。 |
| [データの送信](ams-states.sending-data.md) | このスレッド状態は、スレッドがクエリの行を読み取り、フィルタリングして、正しい結果セットを判断していることを示します。 |
# ソートインデックスの作成
`creating sort index` スレッド状態は、データをソートするために内部テンポラリテーブルを使用する必要がある `SELECT` ステートメントを、スレッドが処理中であることを示します。
**Topics**
+ [サポート対象エンジンバージョン](#ams-states.sort-index.context.supported)
+ [Context](#ams-states.sort-index.context)
+ [待ち時間増加の考えられる原因](#ams-states.sort-index.causes)
+ [アクション](#ams-states.sort-index.actions)
## サポート対象エンジンバージョン
このスレッド状態情報は、以下のバージョンでサポートされています。
+ Aurora MySQL バージョン 2 から 2.09.2 まで
## Context
`creating sort index` 状態は、`ORDER BY` および `GROUP BY` 句を持つクエリが既存のインデックスを使用して操作を実行できない場合に表示されます。この場合、MySQL はより高価な `filesort` オペレーションを実行する必要があります。通常、この操作は結果セットが大きすぎない場合にメモリ内で実行されます。それ以外の場合は、ディスク上にファイルを作成する必要があります。
## 待ち時間増加の考えられる原因
`creating sort index` の表示は、それ自体が問題を示しているわけではありません。パフォーマンスが低下し、頻繁に `creating sort index` の症例が表示される場合、最も可能性の高い原因は `ORDER BY` または `GROUP BY` 演算子を使った遅いクエリです。
## アクション
一般的なガイドラインは、`creating sort index` 状態の増加と関連付けられる `ORDER BY` と `GROUP BY` 句を持つクエリを見つけることです。次に、インデックスを追加するか、ソートバッファサイズを大きくしても問題が解決するかどうかを確認します。
**Topics**
+ [パフォーマンススキーマ がオンになっていない場合は、オンにします。](#ams-states.sort-index.actions.enable-pfs)
+ [問題のあるクエリを特定する](#ams-states.sort-index.actions.identify)
+ [ファイルソートの使用に関する説明プランを調べる](#ams-states.sort-index.actions.plan)
+ [ソートバッファサイズを増やす](#ams-states.sort-index.actions.increasebuffersize)
### パフォーマンススキーマ がオンになっていない場合は、オンにします。
Performance Insights は、パフォーマンススキーマインストゥルメントがオンになっていない場合にのみ、スレッドの状態を報告します。パフォーマンススキーマインストゥルメントがオンの場合、Performance Insights は代わりに待機イベントをレポートします。パフォーマンススキーマインストゥルメントは、潜在的なパフォーマンスの問題を調査するための、追加のインサイトと優れたツールを提供します。したがって、パフォーマンススキーマをオンにすることをお勧めします。詳細については、「[Aurora MySQL における Performance Insights のPerformance Schema の概要](USER_PerfInsights.EnableMySQL.md)」を参照してください。
### 問題のあるクエリを特定する
`creating sort index` 状態の増加の原因となっている現在のクエリを特定するには、`show processlist` を実行して `ORDER BY` または `GROUP BY` を持つクエリがないか確認します。任意で、`filesort` を持つクエリのプロセスリスト ID に `N` がなっている場所で、`explain for connection N` を実行します。
これらの増加の原因となっている過去のクエリを特定するには、スロークエリログをオンにして、`ORDER BY` のクエリを検索します。遅いクエリで`EXPLAIN`を実行し、「filesort を使用しています。」を探します。詳細については、「[ファイルソートの使用に関する説明プランを調べる](#ams-states.sort-index.actions.plan)」を参照してください。
### ファイルソートの使用に関する説明プランを調べる
`creating sort index`状態を引き起こす`ORDER BY` と `GROUP BY` 句を持つステートメントを特定する。
次の例は、クエリで `explain` を実行する方法を解説しています。`Extra` 列は、このクエリが `filesort` を使用していることを示しています。
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
次の例は、`c1` カラムにインデックスが作成された後、同じクエリで `EXPLAIN` を実行した結果を示しています。
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
ソート順の最適化にインデックスを使用する方法については、MySQL ドキュメントの[最適化による注文](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html)を参照してください。
### ソートバッファサイズを増やす
特定のクエリで、ディスク上にファイルを作成した `filesort` プロセスが必要かどうかを確認するには、クエリの実行後、`sort_merge_passes` 可変値をチェックします。例を以下に示します。
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
`sort_merge_passes` の値が高い場合は、ソートバッファサイズを大きくすることを検討してください。この増加をセッションレベルで適用します。グローバルに増やすと、RAM MySQL の使用量が大幅に増加する可能性があるためです。次の例は、クエリを実行する前にソートバッファサイズを変更する方法を示しています。
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# データの送信
`sending data` スレッド状態は、スレッドがクエリの行を読み取り、フィルタリングして、正しい結果セットを決定していることを示します。名前が誤解を招くのは、状態がデータを転送しており、後で送信するデータを収集して準備していないことを意味するためです。
**Topics**
+ [サポート対象エンジンバージョン](#ams-states.sending-data.context.supported)
+ [Context](#ams-states.sending-data.context)
+ [待ち時間増加の考えられる原因](#ams-states.sending-data.causes)
+ [アクション](#ams-states.sending-data.actions)
## サポート対象エンジンバージョン
このスレッド状態情報は、以下のバージョンでサポートされています。
+ Aurora MySQL バージョン 2 から 2.09.2 まで
## Context
多くのスレッド状態は短続きします。中に発生するオペレーション`sending data`大量のディスクまたはキャッシュ読み取りを実行する傾向があります。したがって、`sending data`多くの場合、特定のクエリの存続期間中で最も長い実行状態です。この状態は、Aurora MySQL が次のことをしているときに表示されます。
+ のローの読み取りと処理`SELECT`ステートメント
+ ディスクまたはメモリから大量の読み取りを実行する
+ 特定のクエリからのすべてのデータの完全な読み取りを完了する
+ テーブル、インデックス、またはストアドプロシージャの作業からデータを読み込む
+ データのソート、グループ化、または順序付け
After`sending data`state はデータの準備を終了し、スレッドの状態`writing to net`は、クライアントにデータを返すことを示します。通常、`writing to net`は、結果セットが非常に大きいか、または深刻なネットワークレイテンシーによって転送が遅くなる場合にのみキャプチャされます。
## 待ち時間増加の考えられる原因
`sending data` の表示は、それ自体が問題を示しているわけではありません。パフォーマンスが低下し、頻繁に次のインスタンスが表示される場合`sending data`の場合、最も可能性の高い原因は以下のとおりです。
**Topics**
+ [非効率なクエリ](#ams-states.sending-data.causes.structure)
+ [最適でないサーバー設定](#ams-states.sending-data.causes.server)
### 非効率なクエリ
ほとんどの場合、この状態の原因となるのは、特定のクエリの結果セットを見つけるために適切なインデックスを使用していないクエリです。例えば、カリフォルニアで行われたすべての注文について 1,000 万件のレコードテーブルを読み取るクエリについて考えてみます。ここでは、州の列にインデックスが付けられていないか、インデックスが不十分です。後者の場合、インデックスは存在する可能性がありますが、カーディナリティが低いためオプティマイザはそれを無視します。
### 最適でないサーバー設定
複数のクエリが`sending data`状態の場合、データベースサーバーの設定が不十分である可能性があります。具体的には、サーバーには次の問題が発生する可能性があります。
+ データベースサーバーには、ディスク I/O、ディスクタイプと速度、CPU、または CPU の数など、十分なコンピューティング性能がありません。
+ InnoDB テーブルの InnoDB バッファプールや MyISAM テーブルのキーバッファなど、割り当てられたリソースでサーバーが不足しています。
+ スレッドごとのメモリ設定 (など)`sort_buffer`、`read_buffer`、 および`join_buffer`必要以上に多くの RAM を消費し、物理サーバのメモリリソースが不足しています。
## アクション
一般的なガイドラインは、パフォーマンススキーマをチェックして、多数の行を返すクエリを検索することです。インデックスを使用しないクエリのログがオンの場合、スローログの結果を調べることもできます。
**Topics**
+ [パフォーマンススキーマ がオンになっていない場合は、オンにします。](#ams-states.sending-data.actions.enable-pfs)
+ [メモリ設定の確認](#ams-states.sending-data.actions.memory)
+ [インデックスの使用状況に関する説明プランを調べる](#ams-states.sending-data.actions.plans)
+ [返されたデータの量をチェックする](#ams-states.sending-data.actions.maintenance)
+ [並行性の問題をチェックする](#ams-states.sending-data.actions.concurrent-queries)
+ [クエリの構文を確認します。](#ams-states.sending-data.actions.subqueries)
### パフォーマンススキーマ がオンになっていない場合は、オンにします。
Performance Insights は、パフォーマンススキーマインストゥルメントがオンになっていない場合にのみ、スレッドの状態を報告します。パフォーマンススキーマインストゥルメントがオンの場合、Performance Insights は代わりに待機イベントをレポートします。パフォーマンススキーマインストゥルメントは、潜在的なパフォーマンスの問題を調査するための、追加のインサイトと優れたツールを提供します。したがって、パフォーマンススキーマをオンにすることをお勧めします。詳細については、「[Aurora MySQL における Performance Insights のPerformance Schema の概要](USER_PerfInsights.EnableMySQL.md)」を参照してください。
### メモリ設定の確認
プライマリバッファプールのメモリ設定を確認します。これらのプールがワークロードに合わせて適切なサイズになっていることを確認します。データベースで複数のバッファプールインスタンスを使用している場合は、それらが多数の小さなバッファプールに分割されていないことを確認してください。スレッドが一度に使用できるバッファプールは 1 つだけです。
各スレッドで使用される次のメモリ設定が、適切なサイズであることを確認します。
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
設定を変更する特定の理由がない限り、デフォルト値を使用します。
### インデックスの使用状況に関する説明プランを調べる
`sending data` スレッド状態のクエリの場合、プランを調べて、適切なインデックスが使用されているかどうかを判断します。クエリが有用なインデックスを使用していない場合は、`USE INDEX` や `FORCE INDEX` のようなヒントを追加することを検討してください。ヒントは、クエリの実行にかかる時間を大幅に増減できるので、追加する前に注意してください。
### 返されたデータの量をチェックする
クエリ対象のテーブルと、そのテーブルに含まれるデータの量をチェックします。このデータのいずれかをアーカイブできますか? 多くの場合、クエリの実行時間が短くなる原因は、クエリプランの結果ではなく、処理されるデータの量です。多くのデベロッパーはデータベースにデータを追加するのに非常に効率的ですが、設計および開発段階でデータセットのライフサイクルを考慮することはほとんどありません。
低ボリュームデータベースではうまく機能するが、現在のシステムではパフォーマンスが低下するクエリを探します。特定のクエリを設計するデベロッパーは、これらのクエリが 350,000 行を返していることに気付かないことがあります。デベロッパーは、実稼働環境よりも小さいデータセットを持つ低ボリュームの環境でクエリを開発した可能性があります。
### 並行性の問題をチェックする
同じタイプの複数のクエリが同時に実行されているかどうかを確認します。一部の形式のクエリは、単独で実行すると効率的に実行されます。ただし、同様の形式のクエリを一緒に、または大量に実行すると、同時実行の問題が発生する可能性があります。多くの場合、これらの問題はデータベースがテンポラリテーブルを使用して結果をレンダリングするときに発生します。制限的なトランザクション分離レベルは、同時実行性の問題を引き起こすこともあります。
テーブルが同時に読み書きされる場合、データベースがロックを使用している可能性があります。低いパフォーマンス期間を特定するには、大規模なバッチプロセスでデータベースの使用状況を調べます。最近のロックとロールバックを確認するには、`SHOW ENGINE INNODB STATUS` コマンドの出力を確認します。
### クエリの構文を確認します。
これらの状態からキャプチャされたクエリがサブクエリを使用しているかどうかを確認します。このタイプのクエリは、データベースが内部的に結果をコンパイルし、それらを再びクエリに戻してデータレンダリングするため、パフォーマンスが低下することがあります。このプロセスは、データベースの追加ステップです。多くの場合このステップは、高い同時ロード条件下でパフォーマンスが低下する可能性があります。
また大量の `ORDER BY` および `GROUP BY`句 をクエリが使用していないかも、確認してください。このような操作では、多くの場合、データベースはまずデータセット全体をメモリ内に形成する必要があります。その後、クライアントに戻す前に、特定の方法で注文またはグループ化する必要があります。
# Amazon DevOps Guru のプロアクティブインサイトによる Aurora MySQL のチューニング
DevOps Guru のプロアクティブインサイトは、Aurora MySQL DB クラスターで既知の問題が発生する前に検出します。DevOps Guru では、次のことができます。
+ データベース構成を一般的な推奨設定と照合することで、データベースに関する多くの一般的な問題を防ぎます。
+ 未チェックのままにしておくと、後で大きな問題につながる可能性があるフリート内の重大な問題について警告します。
+ 新しく発見された問題について警告します。
すべてのプロアクティブインサイトには、問題の原因の分析と是正措置の推奨事項が含まれています。
**Topics**
+ [InnoDB 履歴リストの長さが大幅に増加しました](proactive-insights.history-list.md)
+ [データベースはディスク上にテンポラリテーブルを作成している](proactive-insights.temp-tables.md)
# InnoDB 履歴リストの長さが大幅に増加しました
*date* を過ぎると、行変更の履歴リストが大幅に増加し、*db-instance* では最大 *length* になりました。この増加は、クエリとデータベースのシャットダウンパフォーマンスに影響します。
**Topics**
+ [サポート対象エンジンバージョン](#proactive-insights.history-list.context.supported)
+ [Context](#proactive-insights.history-list.context)
+ [この問題の考えられる原因](#proactive-insights.history-list.causes)
+ [アクション](#proactive-insights.history-list.actions)
+ [関連するメトリクス](#proactive-insights.history-list.metrics)
## サポート対象エンジンバージョン
このインサイト情報は、Aurora MySQL のすべてのバージョンでサポートされています。
## Context
InnoDB トランザクションシステムは、マルチバージョン同時実行制御 (MVCC) を維持します。行が変更されると、変更中のデータの修正前のバージョンが、undo レコードとして undo ログに保存されます。すべての undo レコードには、以前の redo レコードへの参照があり、リンクリストを形成します。
InnoDB 履歴リストは、コミットされたトランザクションの undo ログのグローバルリストです。MySQL は、トランザクションで履歴が不要になったときに、履歴リストを使用してレコードとログページを削除します。履歴リストの長さは、履歴リスト内の変更を含む undo ログの総数です。各ログには、1 つ以上の変更が含まれます。InnoDB 履歴リストの長さが大きくなりすぎると、古い行バージョンが多数存在することになり、クエリやデータベースのシャットダウンが遅くなります。
## この問題の考えられる原因
履歴リストが長くなる一般的な原因には次のものがあります。
+ 実行時間の長いトランザクション (読み取りまたは書き込み)
+ 書き込み負荷が高い
## アクション
インサイトの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [InnoDB 履歴リストが減るまで、データベースのシャットダウンを伴う操作を開始しない](#proactive-insights.history-list.actions.no-shutdown)
+ [長時間実行されるトランザクションを特定して終了する](#proactive-insights.history-list.actions.long-txn)
+ [Performance Insights を使用して、上位ホストと上位ユーザーを特定します。](#proactive-insights.history-list.actions.top-PI)
### InnoDB 履歴リストが減るまで、データベースのシャットダウンを伴う操作を開始しない
InnoDB 履歴リストが長くなるとデータベースのシャットダウンが遅くなるため、データベースシャットダウンを伴う操作を開始する前にリストサイズを小さくしてください。これらの操作には、データベースのメジャーバージョンのアップグレードが含まれます。
### 長時間実行されるトランザクションを特定して終了する
`information_schema.innodb_trx` クエリを実行すると、実行時間の長いトランザクションを見つけることができます。
**注記**
リードレプリカで長時間実行されるトランザクションも必ず探してください。
**長時間実行されるトランザクションを特定して終了するには**
1. SQL クライアントで次のクエリを実行します。
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. ストアドプロシージャ [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) を使用して、長時間実行している各トランザクションを終了します。
### Performance Insights を使用して、上位ホストと上位ユーザーを特定します。
トランザクションを最適化して、変更された多数の行がすぐにコミットされるようにします。
## 関連するメトリクス
このインサイトに関連するメトリクスは次のとおりです。
+ `trx_rseg_history_len` – このカウンターメトリクスは、Performance Insights および `INFORMATION_SCHEMA.INNODB_METRICS` テーブルで表示できます。詳細については、MySQL ドキュメントの「[InnoDB INFORMATION\$1SCHEMA metrics table](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html)」を参照してください。
+ `RollbackSegmentHistoryListLength` - この Amazon CloudWatch メトリクスは、コミットされたトランザクションが削除とマークされたレコードを記録する UNDO ログを測定します。これらのレコードは、InnoDB のパージオペレーションによって処理されるようにスケジュールされています。メトリクス `trx_rseg_history_len` の値は `RollbackSegmentHistoryListLength` と同じです。
+ `PurgeBoundary` – InnoDB パージ可能領域の最後のトランザクション番号。この CloudWatch メトリクスが長く進まない場合は、InnoDB パージが長時間実行中のトランザクションによってブロックされていることを示す良い目安となります。調査するには、Aurora MySQL DB クラスターのアクティブなトランザクション数を確認します。このメトリクスは、Aurora MySQL バージョン 2.11 以降およびバージョン 3.08 以降で利用できます。
+ `PurgeFinishedPoint` – InnoDB パージが実行される領域の最後のトランザクション番号。この CloudWatch メトリクスは、InnoDB パージの進行速度を調べるのに役立ちます。このメトリクスは、Aurora MySQL バージョン 2.11 以降およびバージョン 3.08 以降で利用できます。
+ `TransactionAgeMaximum` – 最も古いアクティブな実行中トランザクションの経過時間。この CloudWatch メトリクスは、Aurora MySQL バージョン 3.08 以降でのみ使用できます。
+ `TruncateFinishedPoint` – 切り捨てを元に戻す操作が実行される最後のトランザクション番号。この CloudWatch メトリクスは、Aurora MySQL バージョン 2.11 以降、およびバージョン 3.08 以降でのみ使用できます。
CloudWatch のメトリクスの詳細については、「[Amazon Aurora のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)」を参照してください。
# データベースはディスク上にテンポラリテーブルを作成している
最近のディスク上のテンポラリテーブルの使用率が大幅に増加し、最大 *percentage* に達しています。データベースは、1 秒あたり約 *number* 個のテンポラリテーブルを作成しています。これにより、パフォーマンスに影響が及び、*db-instance* に対するディスク操作が増える可能性があります。
**Topics**
+ [サポート対象エンジンバージョン](#proactive-insights.temp-tables.context.supported)
+ [Context](#proactive-insights.temp-tables.context)
+ [この問題の考えられる原因](#proactive-insights.temp-tables.causes)
+ [アクション](#proactive-insights.temp-tables.actions)
+ [関連するメトリクス](#proactive-insights.temp-tables.metrics)
## サポート対象エンジンバージョン
このインサイト情報は、Aurora MySQL のすべてのバージョンでサポートされています。
## Context
MySQL サーバーがクエリの処理中に内部一時テーブルを作成する必要がある場合があります。Aurora MySQL は、内部一時テーブルをメモリに保持できます。このテーブルは、TempTable または MEMORY ストレージエンジンで処理するか、InnoDB によってディスクに保存したりできます。詳細については、*MySQL リファレンスマニュアル*の「[Internal Temporary Table Use in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html)」(MySQL での内部一時テーブルの使用) を参照してください。
## この問題の考えられる原因
ディスク上の一時テーブルの増加は、複雑なクエリの使用を示しています。設定されたメモリが一時テーブルをメモリに格納するには不十分な場合、Aurora MySQL はテーブルをディスク上に作成します。これにより、パフォーマンスに影響が及び、ディスク操作が増える可能性があります。
## アクション
インサイトの原因に応じて、異なるアクションをお勧めします。
+ Aurora MySQL バージョン 3 の場合、TempTable ストレージエンジンを使用することをお勧めします。
+ 必要な列のみを選択して、クエリを最適化して、返されるデータを減らします。
すべての `statement` 計測が有効で時間制限のある状態でパフォーマンススキーマを有効にすると、`SYS.statements_with_temp_tables` クエリを実行して、一時テーブルを使用するクエリのリストを取得できます。詳細については、MySQL ドキュメントの「[Prerequisites for Using the sys Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html)」(sys スキーマを使用するための前提条件) を参照してください。
+ ソートやグループ化の操作に関係する列にインデックスを付けることを検討してください。
+ `BLOB` および `TEXT` 列を避けるように、クエリを書き直します。これらの列は常にディスクを使用します。
+ `tmp_table_size` および `max_heap_table_size` データベースパラメータをチューニングします。
これらのパラメータのデフォルト値は 16 MiB です。メモリ内一時テーブルに MEMORY ストレージエンジンを使用する場合、最大サイズは、`tmp_table_size` または `max_heap_table_size` 値のいずれか小さい方によって定義されます。この最大サイズに達すると、MySQL はインメモリ内部一時テーブルを InnoDB オンディスク内部一時テーブルに自動的に変換します。詳細については、「[Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)」(Amazon RDS for MySQL および Amazon Aurora MySQL で TempTable ストレージ エンジンを使用する) を参照してください。
**注記**
CREATE TABLE を使用して MEMORY テーブルを明示的に作成する場合、テーブルをどれだけ大きくできるかを決めるのは `max_heap_table_size` 変数だけです。また、オンディスク形式への変換もありません。
## 関連するメトリクス
以下の Performance Insights メトリクスがこのインサイトに関連しています。
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
詳細については、MySQL ドキュメントの「[Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables)」を参照してください。