アダプティブハッシュインデックス（アダプティブハッシュインデックス）

記事ディレクトリ

1.1ハッシュインデックスとは

ハッシュインデックスはハッシュテーブルに基づいて実装されます。インデックスのすべての列に完全に一致するクエリのみが有効です。データの各行について、ストレージエンジンはすべてのインデックス列値のハッシュコードを計算し、ハッシュインデックスはすべてのハッシュコードを計算します。ハッシュテーブルの各データ行へのポインタを格納しながら、インデックスに格納されます。

ハッシュインデックスにはハッシュ値と行ポインタのみが含まれ、フィールド値は格納されないため、ハッシュインデックスをインデックススキャンのカバーに使用することはできません。
ハッシュインデックスデータは、インデックス列の値順に格納されないため、並べ替えには使用できません。
ハッシュインデックスは常にインデックスのすべての列値を使用してハッシュ値を計算するため、ハッシュインデックスは部分インデックス列一致検索もサポートしていません。ハッシュインデックスは、同等の比較クエリのみをサポートします。
ハッシュインデックスデータへのアクセスは非常に高速です。ただし、ハッシュの競合が多い場合を除き、ハッシュの競合がある場合、ストレージエンジンは、リンクリスト内のすべての行ポインタをトラバースし、適格なすべての行が見つかるまで行ごとに比較する必要があります。ハッシュの競合が多い場合、一部のインデックス保守操作もコストがかかります。

1.2アダプティブハッシュインデックスとは

MySQLでは、ハッシュインデックスはメモリエンジンとNDBエンジンでのみサポートされます。メモリエンジンはデフォルトでハッシュインデックスをサポートします。複数のハッシュ値が同じでハッシュの衝突が発生した場合、インデックスはリンクリストに保存されます。一般的に使用されているInnoDBエンジンでは、ハッシュインデックスはサポートされていません。InnoDBでハッシュインデックスをサポートするために、アダプティブハッシュインデックスと呼ばれる疑似ハッシュインデックスで実現できます。

アダプティブハッシュインデックスは、InnoDBがいくつかのインデックス値が非常に頻繁に使用されていることに気付いたときに、メモリ内のbtreeインデックスに基づいてハッシュインデックスを作成し、ハッシュ検索を実行できるようにします。

1.3アダプティブハッシュインデックスの原理

InnoDBストレージエンジンは、テーブル上のインデックスのルックアップを監視します。ハッシュインデックスの確立によって速度が向上することが確認された場合、適応型ハッシュインデックスが確立されます。実現は本質的にハッシュテーブルです。特定の取得条件から特定の条件までデータページのハッシュテーブル。

インデックスは
、特定のインデックスツリーに対してAHIが確立された17回以上を使用します（AHIは、インデックスツリーのレイヤーが多すぎる場合にのみ有効になります）。インデックスが1回または2回しか使用されない場合、そのインデックスに対してAHIが確立されるため、AHIが多すぎて、メンテナンスコストがメリットよりも高くなります。インデックスが17回以上使用されると、フィルターを通過します。

ハッシュ情報は
、17回以上使用されるインデックスのハッシュ情報を作成するために100回以上使用されます。ハッシュ情報は、検索条件とインデックスの間の一致度を表すために使用されます。AHIを設定する際に、一致度に応じてデータの一致部分を抽出し、AHIのキーとして使用することができます。ハッシュ情報の使用回数が100回を超える場合は、ハッシュ情報が頻繁に使用されていることを意味します。

ハッシュ情報構造：一致するインデックス列の数、次の列の一致するバイト数、および左から一致するかどうか。

ハッシュ情報が1/16を超えるページデータにヒットした場合
、テーブル内のすべてのデータに対してAHIを作成すると、AHIはキャッシュの意味を失うため、インデックスツリーで頻繁に使用されるデータページを見つける必要があります。この手順をフィルタリングした後、開始できます。ハッシュインデックスを作成します。

1.4関連変数

mysql>  show variables like '%hash%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| innodb_adaptive_hash_index       | ON    |
| innodb_adaptive_hash_index_parts | 8     |
+----------------------------------+-------+
2 rows in set (0.00 sec)
#innodb_adaptive_hash_index:控制innodb自适应哈希索引特性是否开启参数
innodb_adaptive_hash_index_parts:凡是缓存都会涉及多个缓存消费者间的锁竞争。MySQL通过设立多个AHI分区，每个分区使用独立的锁，来减少锁竞争。

1.5モニタリング指標

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
 #这行显示自适应哈希索引的状态，其中，Hash table size 276707表示AHI的大小， node heap has 629 buffer(s)表示AHI的使用情况
Hash table size 276707, node heap has 2 buffer(s)
Hash table size 276707, node heap has 629 buffer(s)
Hash table size 276707, node heap has 1 buffer(s)
Hash table size 276707, node heap has 0 buffer(s)
Hash table size 276707, node heap has 1 buffer(s)
Hash table size 276707, node heap has 0 buffer(s)
Hash table size 276707, node heap has 2 buffer(s)
Hash table size 276707, node heap has 4 buffer(s)
#这行显示了在show engine头部的时间内Innodb每秒完成了多少哈希索引操作，3999.00 hash  searches/s表示每秒使用AHI搜索的情况，2326.97 non‐hash searches/s表示 每秒没有使用AHI搜索的情况(因为哈希索引只能用于等值查询，而范围查询，模糊查询是不能使用哈希索引的。)，通过hash searches: non‐hash searches 的比例大概可以了解使用哈希索引后的效率，自适应哈希索引无法配置，但是可以通过 innodb_adaptive_hash_index=ON|OFF参数来选择是否需要这个特性
3999.00 hash searches/s, 2326.97 non-hash searches/s

ビジネスのAHI使用率が低すぎる場合は、AHI確立の原則を理解した後、ビジネスがAHIにヒットしない理由を分析して、ビジネスが合理的かどうか、アクセスモードを変更する必要があるかどうか、データをホットとコールドから分離する必要があるかどうかを判断できます。AHIを閉鎖して、AHIの保守コストを削減することも検討できます。

1.6まとめ

MySQLはデータページをクエリするためのキャッシュとしてAHIを導入し、データページをクエリするコストを削減したいと考えています
AHIの「アダプティブ」が解決したい問題は、キャッシュが大きすぎたり小さすぎたりできないことです。
AHIの確立中、一定の制限により、頻繁に使用されるインデックスと頻繁に使用されるデータページのみがキャッシュされます。