# synch/sxlock/innodb/hash\_table\_locks
<a name="ams-waits.sx-lock-hash-table-locks"></a>

`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)

## サポート対象エンジンバージョン
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

この待機イベント情報は、以下のバージョンでサポートされています:
+ Aurora MySQL バージョン 2 および 3

## Context
<a name="ams-waits.sx-lock-hash-table-locks.context"></a>

イベント `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)を参照してください。

## 待ち時間増加の考えられる原因
<a name="ams-waits.sx-lock-hash-table-locks.causes"></a>

`synch/sxlock/innodb/hash_table_locks` 待機イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。

**サイズの小さいバッファープール**  
バッファプールのサイズが小さすぎて、頻繁にアクセスされるすべてのページをメモリ内に保持できません。

**ヘビーワークロード**  
ワークロードによって、バッファキャッシュで頻繁にエビクションとデータページがリロードされます。

**ページの読み取り中にエラーが発生しました**  
バッファープール内のページの読み取り中にエラーが発生しました。これは、データの破損を示している可能性があります。

## アクション
<a name="ams-waits.sx-lock-hash-table-locks.actions"></a>

待機イベントの原因に応じたさまざまなアクションをお勧めします。

**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)

### バッファプールのサイズを増やす
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

バッファプールがワークロードに合わせて適切なサイズになっていることを確認します。そのためには、バッファプールのキャッシュヒット率を確認できます。通常、値が 95% を下回った場合は、バッファプールのサイズを大きくすることを検討してください。バッファプールが大きいほど、頻繁にアクセスされるページをメモリ内に長く保持できます。バッファプールのサイズを増やすには、`innodb_buffer_pool_size` パラメータの値を変更します。このパラメータのデフォルト値は、DB インスタンスクラスのサイズに基づいています。詳細については、[Amazon Aurora MySQL データベース設定のベストプラクティス](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)を参照してください。

### データアクセスパターンの改善
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

この待機の影響を受けるクエリとその実行プランを確認します。データアクセスパターンの改善を検討してください。例えば[mysqli\_result:: fetch\_array](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/)を参照してください。

### フルテーブルスキャンの削減または回避
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

ワークロードをモニタリングして、フルテーブルスキャンが実行されているかどうかを確認し、実行している場合はそれを減らすか回避します。例えば、`Handler_read_rnd_next` のようなステータス可変をモニタリングできます。詳細については、MySQL ドキュメントの[サーバーステータス可変](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next)を参照してください。

### エラーログでページの破損を確認します。
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

mysql-error.log をチェックして、問題の発生時に検出された破損関連のメッセージを確認できます。問題を解決するために作業できるメッセージは、エラーログに記録されます。破損として報告されたオブジェクトを再作成する必要がある場合があります。