从数据结构上理解联合索引

        我在上一篇MySQL底层数据结构选用B+树的原因文章中解释了MySQL为什么要用B+树保存索引，对于用单列创建的索引来说，我们可以很好地理解他是如何构建出B+树的，但是如果是用多列创建的联合索引呢，他又是如何构建出B+树的呢？

        一开始，我以为是用什么特殊的算法把多个列计算出一个特殊的值来构建出和单列索引一样的B+树，但后来细想一下发现不对劲，首先，用这样的方式构建B+树那么将带来hash索引的所有缺点，而且如果用这种方法创建B+树的话，那么这个联合索引就只有查询条件覆包含索引的所有列才能生效。比如：用c1,c2,c3创建索引，那么就只有在查询条件包含c1,c2,c3时这个索引才生效，少任何一个都不行，这与我对联合索引使用印象不符。

        然后查了相关的资料后，了解到联合索引构建的B+树大致是长这样：

        上图是由c1,c2,c3三个列创建的联合索引所构建出的B+树。树的非叶子节点保存了联合索引的所有列，叶子节点还保存了主键，构建B+树时，优先根据c1的值进行排序，如果有相同值再根据c2的值进行排序，以此类推。查询时也会优先根据c1的条件进行匹配，然后匹配c2，最后是匹配c3。这个过程下图可能会更清晰一些。

        可以看到，第一行是根据从小到大排序的，在第一行相同的情况下，再根据第二行进行排序，以此类推。在进行查找时也是如此，先会根据索引的第一个列进行比较，再根据索引的第二个列进行比较，以此类推。注意，这个索引的第一个列和第二个列指的是创建索引时列的顺序，与where条件的顺序无关。所以，在使用时，创建了 c1,c2,c3的联合索引后，可以看成创建了(c1),(c1,c2),(c1,c2,c3)三个索引。那为什么没有(c3),(c2),(c1,c3),(c2,c3)这样的索引呢？

        可以看到，在只看第二行，或者只看第三行的情况下，大小顺序是乱的，所以也就没有(c3),(c2),(c1,c3),(c2,c3)这样的索引。这也是联合索引最左匹配原则的原理。