MySQL 索引机制背后的隐藏之道

索引的 “哲学思想”

我们为什么需要索引？

显而易见，使用索引可以加快我们检索数据的速度，生活中书籍的目录、图书馆里的各种书架编号、号码簿上的检索页等，都少不了索引的身影。

回到计算机的世界，任何一种数据结构都不是凭空产生的，一定会有它的诞生背景和解决的问题。我们先举个最简单的例子，下图是一个有序递增的数组，里面包含十个元素，没有重复。

如果我想要查找元素 24 ，该怎么做呢？第一想到的自然是遍历数组，如果数组长度为 N 那么算法的时间复杂度是 O(N)。有没有更快的办法呢？随即我们想到，鉴于数组已经有序了，我们还可以使用二分查找，每次都折半，时间复杂度降为 O(logN)。甚至于，我们还可以建立树形的数据结构来搜索，最常见的就是二叉搜索树（BST）或者 AVL 树。

到目前为止，好像一切都很容易，下面我们为之前的数据再增加一个关联的数据属性（或者多个数据属性）。

看看是不是有点眼熟，好像这种结构在哪里见过？想象一下，将这个数据集横向拓展，发现这其实就是数据库中一张表，它有两列，一列主键一列数字，其中第一行的数据就对应数据库表的主键（Primary Key），每个 PK 关联与之对应的一整行数据记录。

回想下我们刚刚做的努力，我们用 PK 的值来构建了某种查询数据结构（例如 BST、AVL），然后通过它快速找到了 PK 的值，如果树的节点保存一整行的记录，那么当我们的查询命中某个 PK 之后，就能在该节点顺势读取到这一行其他的数据了。

例如我们查询主键为 27 的节点，便可以顺势读到第二行的 7 这个数值。

上述的例子是很显而易见的，即使你没接触过索引，要设计一种加速查询的方法，也可能会想到这种方案，但是仅仅做到这些远远不够，数据库系统受庞大的数据量、查询条件的复杂性（等值、范围、模糊）的影响，其索引的实现复杂许多，但是起源的哲学思想都是一样的。

索引是越多越好吗？

虽说索引可以加速查询，但索引未必是越多越好，因为：

• 数据的增删都会涉及到随索引的修改，索引越多维护成本越高；
• 索引越多也意味着存储空间需要越大；
• 有时候未必需要索引，如果一列数据重复项非常多，建索引反而没有必要，例如第一节中我们列举了一个内存中、极少量数据如何采用不同的方