c
1
b
90
其实我在另外一篇分享「大话mysql索引」里面有介绍mysql数据和索引实际的存储结构，这个存储结构就是解答这个问题的关键所在！
5
k
u
q
3
这里就涉及到一个很严重的问题，由于我们的数据是按照colum_1排序的，所以导致了colum_2局部有序但整体完全无序，所以其实mysql服务器也没有办法，如果强行让mysql用上这个索引会发生下面这个现象：1. 首先遍历一边整个索引，然后再根据找到的结果再去回表；可以看到，其实还是要全部扫描一遍，mysql服务器需要检索的数据一条都没有少，而且还多了一个回表操作。。。这。。。还不如直接用聚集索引全表扫。。。
h
f
s
a
44
j
d
6
这里先简化一下真实的存储结构
id列
18
8
12
colum_3(varchar)
2
4
99
l
其实由于colum_1已经是有序的了，所以我们直接二分法找到colum_1=c的位置，然后找到所有左边的数据不就行了吗？索引就这么被用上了：span style=\"font-size: inherit;\
7
colum_2(int)
20
17
v
colum_1(varchar)
那么针对上面这个索引，如果我要查询where colum_1 = 'b' and colum_3 = 'u'; 怎么找呢？
那么针对上面这个索引，如果我要查询where colum_2 = 3; 怎么找呢？
那么针对上面这个索引，如果我要查询where colum_1 < 'c'; 怎么找呢？
34
9
这里可以看到当我们新建了col1/2/3这样一个联合索引后，数据的真实存储是会按照下面这个顺序存储的：1. 首先按照colum_1的顺序排，从左到右依次增大；2. 如果colum_1的大小一样的时候，按照colum_2的顺序排，从左到右依次增大；3. 如果colum_2的大小一样的时候，按照colum_3的顺序排，从左到右依次增大；4. 中间的存索引列的值，最后叶子结点存放对应的主键列，用于回表（二级索引都是这么玩的啦）。
索引下推
大家都知道当where后有多列查询的时候，可以通过新建多列的联合索引来提高查询性能，而且你去查资料都会跟你说多列索引符合最左匹配原则。那么，你是如何理解这个原则的呢？当你explain一下sql的时候发现，唉！还真的是哈！但是为啥时这样的呢？这里我将自己学习的用自己的理解记录一下！也方便大家理解！
其实原因已经出来了！就两个字很简单：无序！那你会说，整这么多原来就是无序啊，直接说不就行了吗？不行，文字有时候就是苍白的，比如我现在想知道为啥无序就不行呢？---> 因为我们不能忘了索引的本质：b+树是一颗有序的树结构，如果无序的话连基本的数据结构都不对还这么生效呢？！是不是豁然开朗！！！
