MySQL-Btree索引和Hash索引初探
文章目录
官方文档
如果英文不好的话，可以参考 searchdoc 翻译的中文版本
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
MySQL支持的索引类型
MySQL的索引是在存储引擎层面实现的，而不是MySQL服务层。
B树索引
B树索引的特点
B-tree索引是以B+树的结构存储数据的。
那我们先简单的来了解B+树
- 平衡查找树，每一个叶子节点到根节点的距离都是相同的
- 叶子结点都是按照顺序从小到大排在同一层上
- 叶子节点是由指针来连接的
方案查找
B树索引的特点
- B-tree索引能够加快数据的查询速度
- B-tree索引更适合进行范围查找，因为数据 是顺序存储的
什么情况下会使用到B树索引
这里我们以订单表为例子来说明
-
全职匹配的查询
在order_sn 上建立B树索引
比如 查询 订单序列号 order_sn = ‘123456’
-
匹配最左前缀的查询
举个例子：订单表 order_sn 没有索引， 但有个联合索引建在在 order_sn + order_date 这两个字段上
当查询 order_sn = ‘123456’ ----> 走索引
当查询 order_sn = ‘123456’ and order_date = ‘2020-01-20’----> 走索引
当查询 order_date = ‘2020-01-20’----> 不走索引这就是 匹配最左前缀的查询
-
匹配列前缀查询
举个例子 在order_sn 上建立B树索引
order_sn like '123% '-------------> 走索引
-
匹配范围值的查询
比如 order_sn上建立索引
order_sn > '1000000' and order _sn < '1100000'-----------> 走索引
-
精确匹配左前列并范围匹配另外一列
继续使用例子： 订单表 order_sn 没有索引， 但有个联合索引建在在 order_sn + order_date 这两个字段上
比如 精确匹配 order_sn 但 order_date是个范围查询 -----> 走索引
-
只访问索引的查询
意思就是 order_sn上有索引， 我查询的时候仅仅查询这一列（索引列），而其他的数据列我不获取。 效率非常高这种情况。
Btree索引的使用限制
-
如果不是按照索引最左列开始查找，则无法使用索引
继续使用例子： 订单表 order_sn 没有索引， 但有个联合索引建在在 order_sn + order_date 这两个字段上
如果你仅仅查询order_date , 这个联合索引，是不会走的。
-
使用索引时不能跳过索引中的列
举个例子： 3个列建立联合索引 order_date + contact_people + contact_phone
如果你查询中仅包含了 order_date 和 contact_phone , 对于这个查询来讲 ，只能使用到使用order-date来索引，而没法走contact_people 了，因为你跳过了contact_people .
-
not int 和 <> 操作无法使用索引
-
如果查询中有某个列的范围查询，则其右边所有列都无法使用索引
hash索引
我们知道，索引是有存储引起来实现的， 而MySQL的存储引擎又是插件式的，所以其他的存储引擎比如Memory存储引擎就支持 hash 索引 和 B树索引。 memory的默认索引就是hash索引，我们还是有必要了解下的。
innodb也支持hash索引，不够不是由开发人员建立的，innodb内部自己定义的。
hash索引的特点
- 基于hash表实现， 只有查询条件精确匹配时hash索引中的所有列时，才能够使用到hash索引
- 对于hash索引中的所有列，存储引擎都会为每一行计算一个hash码，hash索引中存储的就是这个hash码
hash索引的限制
- hash索引必须进行二次查找 ，但基于内存，速度也挺快
- 无法用于排序
- 不支持部分索引操作 也不支持范围查找
- hash码的计算可能存在hash冲突
为啥要使用索引
- 索引大大减少 存储引擎需要扫描的数据量
- 索引可以帮助我们进行排序以避免使用临时表
- 索引可以把随机I/O 变为 顺序I/O
小结
索引不是越多越好 ，索引过多
-
对写的影响： 过多索引会增加写操作的成本，比如有的时候批量导入数据，你觉得慢，可以把索引先禁用，导入完成后再开启索引
-
对读的影响： 过多索引会增加查询优化器的选择时间。