全网都在说一个错误的结论

大家在背 MySQL 八股文的时候，是不是经常看到这句话。

联合索引的最左匹配原则会一直向右匹配直到遇到范围查询(>、<、between、like) 就会停止匹配。

我随手在网上搜了下， 基本全部都是这个结论，似乎这个结论大家都耳濡目染了，应该大多数人都觉得这个结论是正确的吧。

我在昨晚折腾了几个实验，发现这个结论并不全对！去掉 「between 和 like 」这个结论就没问题了。

经过实验的证明，我得出的结论是这样的：

联合索引的最左匹配原则，在遇到范围查询（如 >、<）的时候，就会停止匹配，也就是范围查询的字段可以用到联合索引，但是在范围查询字段后面的字段无法用到联合索引。但是，对于 >=、<=、BETWEEN、like 前缀匹配这四种范围查询，并不会停止匹配。

接下来，我会用几个实验例子来说明这个结论。

B+Tree 索引

首先，先来认识下 B+Tree 索引。

MySQL 的 InnoDB 存储引擎会为每一张数据库表创建一个「聚簇索引」来保存表的数据，聚簇索引默认使用的是 B+Tree 索引。

为了让大家理解 B+Tree 索引的存储和查询的过程，接下来我通过一个简单例子，说明一下 B+Tree 索引在存储数据中的具体实现。

假设有一张商品表，表里有这些数据：

这些数据，存储在 B+Tree 索引时是长什么样子的？

B+Tree 是一种多叉树，叶子节点才存放数据，非叶子节点只存放索引，而且每个节点里的数据是按主键值（id）顺序存放的，每一层父节点的索引值都会出现在下层子节点的索引值中，因此在叶子节点中，包括了所有的索引值信息，并且每一个叶子节点都指向下一个叶子节点，形成一个链表，便于范围查询。

聚簇索引的 B+Tree 如图所示：

假设，执行了 select * from t_product where id = 5 查询语句，该查询语句的条件是找到 id（主键）为 5 的这条记录。因为 B+Tree 是一个有序的数据结构，所以可以通过二分查找算法快速定位到这条记录，这也就是我们常说的索引查询，具体过程如下：

• 从根节点开始，将 5 与根节点的索引数据 (1，10，20) 比较，5 在 1 和 10 之间，根据二分查找算法，找到第二层的索引数据 (1，4，7)；
• 在第二层的索引数据 (1，4，7)中进行查找，因为 5 在 4 和 7 之间，根据二分查找算法，找到第三层的索引数据（4，5，6）；
• 在叶子节点的索引数据（4，5，6）中进行查找，然后我们找到了索引值为 5 的这条记录。

聚簇索引只能用于主键字段的快速查询，如果想实现「非主键字段」的快速查询，我们就要针对「非主键字段」创建索引，这种索引称作为「二级索引」。二级索引同样基于 B+Tree 实现的，不过二级索引的叶子节点存放的是主键值，不是实际数据。

我这里将前面的商品表中的 product_no （商品编码）字段设置为二级索引，那么二级索引的 B+Tree 如下图，其中非叶子的索引值是 produ