Hash supports only =,>,> =, <, <=, between. BTree like to support fuzzy queries
Mysql index is to help get the data structure of the data. The most common index is Btree index and Hash index.
Different engines have different support for the index: Innodb and MyISAM default index is Btree index; and Mermory default index is Hash index.
We used neither index and Hash algorithms BTree in mysql, two algorithms to retrieve a different way, the role of the query are not the same.
A, BTree
BTree mysql index is the most common database indexing algorithm, because it not only can be used in =,>,> =, <, <=, and the comparison between these operators, like but also for the operator, as long as its query that does not begin with a wildcard character constants, such as:
SELECT * WHERE from User name like 'Jack%';
SELECT * WHERE from User name like 'JAC% K%';
if a wildcard character at the beginning of, or without the use of a constant, not will use an index, for example:
SELECT * WHERE from User name like '% Jack';
SELECT * WHERE User name from simply_name like;
Two, Hash
Hash index can only be used for comparison and the like, for example, =, <=> (= equivalent) operator. Because it is time positioning data, unlike BTree index needs from the root to the branch node, the last node to access to the page so many times IO access, so the retrieval efficiency is much higher than BTree index.
But why do we use BTree than using Hash it? Hash itself mainly because of its specificity, it also brings a lot of limitations and drawbacks:
- Hash indexes can only meet the "=", "IN", "<=>" query, you can not use range queries .
- Joint index, Hash index can not use part of the index key query.
For more than one column joint index, Hash is either all use or not to use all, it does not support the joint index BTree support optimal prefix, which is the joint index of the previous one or a few key index query, Hash index can not be used. - Hash index data sorting operations can not be avoided
due to the Hash index is stored after Hash calculated Hash value and the Hash value of the magnitude relationship and values are not necessarily exactly the same as before the Hash operation, so the database can not be used to index data avoid any sort operations. - Hash index at any time can not avoid the table scan
Hash index after the index key by the Hash operation, the Hash operation result Hash value and row pointer corresponding to the information stored in a Hash table, due to the presence of the same Hash value different index keys, so even if the number of records that satisfy some key data Hash, Hash could not complete the query from the index directly, or to access the table by comparing the actual data and the corresponding results. - Hash index encountered after a large number of Hash value are equal BTree performance is not bound to a high
selectivity for a relatively low index key, if you create an index Hash, then there will be a large number of records stored in the pointer information associated with a Hash value. In this way to locate one of the logs will be very troublesome, will waste many times table data access, resulting in overall performance underneath.
1. hash index lookup data has been able to locate data once, of course, a large number of collisions, then performance will fall. The btree index have to look at the next node, and it is clear to pinpoint efficiency in the data hash index is higher than the btree;
2. so imprecise find it also very clear, because the hash algorithm is based on equivalence computing, so for "like" and other range discovery hash index is invalid, not supported;
3. btree support for the joint index optimal prefix, hash is not supported by the joint index the fields with either all-or-not. Lift the optimal prefix were all thrown confused, and sometimes it seems too much venting;
4. hash indexes do not support the sort, index value and the calculated hash value is not necessarily the same size.
Reprinted from: https://www.cnblogs.com/baizhanshi/p/11084539.html