Article Directory
1.1 What is a hash index
The hash index is implemented based on a hash table. Only queries that exactly match all the columns of the index are valid. For each row of data, the storage engine will calculate a hash code for all index column values, and the hash index will all Stored in the index, while storing a pointer to each data row in the hash table.
- The hash index only contains the hash value and row pointer, and does not store the field value, so the hash index cannot be used for covering index scans.
- Hash index data is not stored in the order of the value of the index column, so it cannot be used for sorting.
- The hash index also does not support partial index column matching search, because the hash index always uses all the column values of the index to calculate the hash value. The hash index only supports equivalent comparison queries.
- Access to hash index data is very fast, unless there are many hash conflicts, when there are hash conflicts, the storage engine must traverse all the row pointers in the linked list and compare row by row until it finds all eligible rows. If there are many hash conflicts, some index maintenance operations are also expensive.
1.2 What is an adaptive hash index
In MySQL, hash indexes are only supported by Memory and NDB engines. The Memory engine supports hash indexes by default. If multiple hash values are the same and hash collision occurs, then the index is stored in a linked list. For our commonly used InnoDB engine, hash index is not supported; to make InnoDB support hash index, it can be realized by pseudo hash index, called adaptive hash index.
Adaptive hash index is that when InnoDB notices that some index values are used very frequently, it will create a hash index based on the btree index in memory, so that it can perform a hash search.
1.3 Principle of Adaptive Hash Index
The InnoDB storage engine monitors the lookup of the index on the table. If it is observed that the establishment of a hash index can bring speed improvement, then an adaptive hash index is established. The realization is essentially a hash table: from a certain retrieval condition to a certain A hash table of data pages.
The index uses more than 17 times
AHI is established for a certain index tree (AHI can only be effective when the index tree has too many layers). If an index is only used once or twice, then AHI is established for it, which will result in too much AHI and maintenance costs higher than benefits. When an index is used more than 17 times, it passes the filter.
Hash info is used more than 100
times to create hash info for indexes that are used more than 17 times. Hash info is used to describe the matching degree between the conditions of a search and the index. When establishing AHI, you can extract the matched part of the data according to the degree of matching and use it as the key of AHI. When the number of uses of hash info is greater than 100, it means that the hash info is frequently used.
- Hash info structure : the number of matching index columns, the number of matching bytes in the next column, and whether to match from the left.
If hash info hits page data greater than 1/16,
if we create AHI for all data in the table, then AHI loses the meaning of caching, so we need to find out the frequently used data pages on the index tree, and we can start after filtering through this step Build a hash index.
1.4 Related variables
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 Monitoring indicators
-------------------------------------
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
If the AHI usage rate of your business is too low, after understanding the principles of AHI establishment, you can analyze why the business does not hit AHI to determine whether the business is reasonable, whether it is necessary to change the access mode or isolate the data from hot and cold. You can also consider closing AHI to reduce AHI maintenance costs.
1.6 Summary
-
MySQL introduces AHI as a cache for querying data pages, and wants to reduce the cost of querying data pages
-
The problem that AHI "adaptive" wants to solve is that the cache cannot be too large or too small
-
During the establishment of AHI, through constant restrictions, only frequently used indexes and frequently used data pages are cached