最近在读MySQL的技术内幕, MySQL的Index之前在MySQL读书笔记的混乱整理中简单提到过, 简单介绍了一下其数据结构. 了解了其结构就可以更加容易理解其Index的工作机制. 本文以个人理解整理, 或有谬误恳请指正.
B+树 (Balance+ Tree)
其实MySQL 索引工作的过程, 就是B+ 树的一个搜索过程, 可以类比二分搜索树(Binary Search Tree)的搜索过程. 由于其每个节点指向的子节点不是2个,而是多个(通常大于2个), 所以B+树是平衡(Balance)树, 而不是二叉(Binary)树.
Index 的工作流程
首先通过用户索引条件(不是WHERE的所有条件), 找到索引所在的页
SQL层读取索引页
通过WHERE条件过滤(内存中完成)
如果是辅助索引, 还需要通过过滤出来的数据, 根据对应的主键索引去读取具体的数据(即, 在聚集索引上重复1,2,3步骤).
索引优化
Index 的优化基本都是围绕IO来进行的, 通常的思路是:
减少IO操作的数据量
提高IO的访问速度, 减少离散读取
覆盖索引 (Covering Index)
当需要查询的数据非常少, 并且条件的辅助索引能够满足要求时, MySQL会选择辅助索引而不是聚集索引. 因为聚集索引页中存储的是完整的数据, 此时如果走聚集索引产生的IO量将远大于辅助索引. 为了减少IO优化器会选择辅助索引.
不使用索引
在某些Range查询或者JOIN操作中, 数据库可能不选在索引查询. 而是通过扫描聚集索引(全表扫描)来完成查询: 当索引不能覆盖到我们需要查询的数据时, 如 select * from t where t.o_no >= 100 and t.o_no <= 10000 此时需要查询的数据是一整行, o_no 索引并不能获取到所有的需要的数据. 此时如果查询的数据范围占到整体数据的一部分时(通常是20%)优化器选择以聚集索引来查找数据. 目的是避免辅助索引之后的离散读取(随机IO), 充分利用磁盘的顺序读写性能.
Multi-Range Read (MRR, 5.6开始支持)
使用辅助索引, 在索引的工作流程中, 通过1,2,3步骤之后, 为了减少聚集索引的随机IO操作, 优化器会先对查询的结果按照主键进行排序后再读取数据, 以减少随机IO操作.
Index Condition Pushdown (ICP, 5.6开始支持)
执行SQL时, 数据库在去除索引的同时判读是否可以进行WHERE条件过滤, 将WHERE的部分过滤操作放在存储引擎层. 以减少SQL层对数据的索取(fetch)操作, 减少IO提高查询性能.