— — 写在前面

记得刚开始工作那会，年轻无知 [dog]，有一段时间对 MySQL 的索引极为迷惑，看公司的 wiki 有着一堆的使用规则，于是我就挑了其中的一个询问了一位 年长的老湿傅，“为何联合索引要最左则原则？” ，湿傅：“这常识问题啊？就我们在使用的时候应该.......”。我 ....... 所以在回答别人问题的时候最好还是要有点深度准备好了再说，否则 [dog][dog][dog] 此处省略一万字 .....
后来经过业余时间的资料补充，可算是了解了一点皮毛，以此一来不管是在平时的使用、设计都有诸多的好处。最近又看到一些文章，于是决定我也来做碗汤，下文主要就围绕 Innodb 来讲解其页结构、B+ Tree 主键索引、及联合索引和普通索引。最后的答案也就随之浮现。为何会有这么多的使用原则？

一、索引的作用

索引，当然是为了提高查询或检索的效率。就举个通俗的栗子吧，我们在使用汉字字典拼音查询时，比如要查询 某个字时，是不是需要从其拼音的开头字母开始查询，慢慢缩小其查询的范围，最终找到匹配的拼音的索引页，定位到所要查询的字。而在数据库中索引的作用也是如此。

二、聚簇索引和非聚簇索引

对于聚簇索引，其实就是叶子节点的顺序和物理存储的顺序是一样的，所以其 范围查询效率很高，任何事物都是有两面性的，所以它的弊端就是在一些DML操作的时候，需要涉及到数据的位移。聚簇索引的顺序就是数据的物理储存顺序，所以这样一来，一个表就只能有一个聚簇索引。（ MySQL Innodb 中默认为主键，当然没有定义主键， InnoDB 会隐式定义一个主键 ）
对于非聚簇索引本文就不做太多介绍，其叶级页指向表中的记录行（ 实际上就是内节点会存储指针，指向记录的物理地址 ），所以其物理顺序与逻辑顺序是没有联系的。

三、MySQL InnoDB 数据页结构

额 .... 这块其实内容比较多，围绕本文的核心，我就挑 Page Directory （ 页目录 ） 来说下吧。
上面说到查字典，总得有个目录去找到对应的数据吧 （ 有目录当然是为了更好的管理数据 ）。在 InnoDB 中是分为数据页和索引页的。
所以 MySQL 为了方便管理这些记录，就规定了用页作为基本单位存放记录，默认的大小是 16 KB，所以一页能存放多少数据是由这些记录的大小决定的，比如一条记录的大小为 10字节的话，那么 16 * 1024 / 10 = 1,638.4 ，所以大约一页可以存放 1638 条记录（ 理论值 ）。那么数据量一多肯定会存在多页，那么页与页之间是怎么关联的呢？见下文图一。
Page和B+树之间并没有一一对应的关系，Page 只是作为一个 Record的 保存容器，它存在的目的是便于对磁盘空间进行批量管理。

图一 InnoDB 页目录剖析图
原图地址： https://www.processon.com/view/link/6077c33de0b34d16663efd0d

四、B+ 树 （ B+ Tree ）

这里推荐大家一个网站，可以去模拟各种数据结构的插入、删除、转换过程。https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
所以我这边在此 乱序 插入了一些数据（ 7,8,9,12,15,18,24,27 ），生成了 Degree 为 3 的 B+ 树。

图二 B+ Tree 索引数据结构模拟
不难发现，其有以下特点：

• 叶子结点包含了所有结点，除叶子结点之外，其它结点不包含值，而叶子结点包含具体的值
• 层级更低（ 相比B树，此文不做 B 树分析 ），叶子结点形成 链表（ 有序 ），范围查询（留个心眼）方便；
  由此，经过一些官方资料查阅，画了一张 InnoDB 引擎中的 B+ 树索引的数据结构图：
  图三 InnoDB 索引数据结构
  原图地址：https://www.processon.com/view/link/6077a5ae0791293688854242

五、联合索引和普通索引

上文二中曾提到因为其本质结构原因一个表就只能有一个聚簇索引，而 InnoDB 默认的聚簇索引就是 主键，那么联合索引和普通索引在查询时是怎么使用的呢？
为此，根据个人的理解本人作图以便于更直观的理解。

图四 联合索引或普通索引检索流程（ 回表 ）
以此上图，当我们在新建一个普通索引或者联合索引时，回去维护类似上图的一个数据结构，当我们在查询时 MySQL 查询分析器选择的是普通索引时，会先通过索引字段找到普通索引数据页。从而找到对应数据的主键位置，再通过主键去检索到所对应的精确行。是不是感觉有点类似于非聚簇索引（ 但是有区别哈 ）。再观察上图，联合索引的排列方式，是不是一眼忘川了为何开发中经常提到的 最左则原则呢。

六、为何 MySQL 会选择 B+ 树作为索引？

A、相对于 B 树

读取成本（ IO 次数 ）：B+树的非叶子结点没有存储数据，所以如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读内存中的需要查找的关键字也就越多。
查询效率：由于B+树的分支结点并不是最终指向文件内容的结点，只是叶子结点的索引，所以任意关键字的查找都必须从根节点走向分支结点，查询路径相同。但B树的分支结点保存有数据，所以查询路径可能不同。

B、相对于 Hash 索引

Hash 应该无需多言了，Hash 的优势是在于精确定位查询，常见的有 HashMap ，但不适合做范围查询
Hash 索引每次查询时都需要将所有的索引数据加载到内存中，而 B+ 索引只需要选定某个范围，再加载到内存中，进行检索。

写在最后

自下而上的分析，根据文章中一些标红的地方，不难发现也就是 MySQL 的一些优势和一些规则的来源也就浮现出来了。另外，了解这些东西只是为了更加清晰的对 MySQL 索引有个稍微深层次的一个认知，才能够运用得当。