# 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 インデックスをオンにすることを検討してください。