1)聚簇索引中的每个叶子节点包含 primary key 的值,事务 ID 和回滚指针(rollback pointer)——用于事务和 MVCC,和余下的列(如 col2)。
2)相对于 MyISAM,辅助索引与聚簇索引有很大的不同。InnoDB 的二级索引的叶子包含 primary key 的值,而不是行指针(row pointers),这减小了移动数据或者数据页面分裂时维护二级索引的开销,因为 InnoDB 不需要更新索引的行指针。
2、MyISAM 引擎方式索引图示
MyISAM 不支持聚簇索引,索引中每一个叶子节点仅仅包含行号(row number),且叶子节点按照 col1 的顺序存储。
在 MyISAM 中,primary key 和其它索引没有什么区别。Primary key 仅仅只是一个叫做 PRIMARY 的唯一,非空的索引而已。
好了,我们还是回到问题本身。
我们其实可以得出这样一个初步结论:
Case1:select id from cities limit 1;
因为 uniq_city_code 索引中包含 id 字段,此查询可以从 uniq_city_code 索引中直接取得数据,所以优化器选择走 uniq_city_code 索引;
Case2:select * from cities limit 1;
此查询中 select * 选取了在 uniq_city_code 索引中不包含的列,所以无法使用 uniq_city_code 这个索引。
为了验证一下我们刚刚得到的初步结论,我们来利用 Case3 验证一下。
Case3:select id, city_code from cities limit 1;
执行结果:
按照上述的理论依据,Case1(查询 id)与 Case3(查询 id+city_code)执行应用的查询计划应该是一致的。
通过验证实验我们可以确定一个结论:Case1 的查询确实存在索引覆盖情况。
官方辅证
我们再继续追问一下:为什么要用到索引覆盖呢?不用可不可以呢?
我们先来看看 MySQL 官方的解释...
其实说了这么多,本质就是最后一句,这样做可以使查询更快!
好了,大家可以一起来思考下这个问题:
“既然主键索引包含所有数据列,那么使用主键索引一样可以做到索引覆盖,为什么优化器不选择使用主键索引?”
......
其实这个问题,就是典型的 MySQL 索引选取原则。
MySQL 在做全表扫描时,MySQL 会调用 find_shortest_key() 来选取最短的索引来扫描。
关于 find_shortest_key()函数的解释,我们来看下官方解释,如下所示:
所以,上面大家一起思考的这个问题,答案就是:索引长度不同,有多个可选索引时,MYSQL 会优先选择较短的索引。
到现在,那我们可以对整个问题做个总结了:因为辅助索引一定是主键索引的子集,从节约 IO 的角度,在全表扫描时优先选择辅助索引。
总结
好了,最后我们一起来对整个分享做下总结吧。
1)首先我们遇到一个查询问题,由于查询字段的不同导致我们的查询结果数据存在差异;
2)我们对问题进行追究,发现根据 select 的字段不同,MySQL 选取的索引策略不同,即结果数据不同;
3)对于是否存在索引覆盖问题,我们进行了 Case3 的验证,确认了存在索引覆盖的问题;
4)对于 MySQL 为什么会存在这样的索引选取原则,我们最终发现是辅助索引一定是主键索引的子集,从节约 IO 的角度,在全表扫描时优先选择辅助索引。
重点提炼:
不同引擎对于查询实现方式的不同、索引覆盖、MySQL 索引选取原则。
不同引擎对于查询实现方式的不同、索引覆盖、MySQL 索引选取原则。
不同引擎对于查询实现方式的不同、索引覆盖、MySQL 索引选取原则。
重要的问题说三遍,哈哈哈~
其实踩坑,也是一种成长!
其实面对任何问题,都不要一上来就急于给出结论,可以尝试多做些深入分析,了解本质问题之后再考虑解决办法进行解决,希望大家能够掌握问题分析以及解决的能力,去触类旁通,而不是仅仅了解一招一式,盲目照搬。
本文地址:百科问答频道 https://www.neebe.cn/wenda/936639_2.html,易企推百科一个免费的知识分享平台,本站部分文章来网络分享,本着互联网分享的精神,如有涉及到您的权益,请联系我们删除,谢谢!