对联合索引 (a, b, c)，如果有如下的 SQL：select a, b, c from test where a=1 and b=2。那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，从而淘汰了很多的随机 IO 操作。而淘汰 IO 操作，而淘汰随机 IO 是 DBA 主要的优化策略，在真正的实际应用中，覆盖索引是主要的提拔性能的优化手段之一。
2-3、进步服从
联合索引的字段越多，通过索引筛选出的数据越少。假如有 1000W 条数据的表，有如下 sql: select * from table where a=1 and b=2 and c=3，假设每个条件可以筛选出 10% 的数据，如果只有单值索引，那么通过该索引能筛选出 1000W * 10% = 100w 条数据，然后再回表从 100w 条数据中找到符合 b=2 and c=3 的数据，然后再排序，再分页。
但如果是联合索引，则通过索引直接筛选出的数据为：1000w * 10% * 10% * 10% = 1w，这服从的提拔可想而知！
四、最左前缀匹配原则（告急）
1、最左匹配原则的规则
最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，如允许以进步查询服从。
最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配（相关阅读：联合索引的最左匹配原则全网都在说的一个错误结论）。
2、索引是否见效的场景
是否满足最左匹配原则是衡量联合索引掷中与否的依据。存在的场景比力多，假设我们创建了以 a, b, c 三个字段的联合索引 idx_abc(a, b, c)，下面我们分别展开讨论索引是否失效的场景。
2-1、全字段全值匹配
索引的全部字段都在查找条件当中，并且都是使用 = 进行全值匹配的情况下，索引是掷中见效的：
select * from table_name where a = '1' and b = '2' and c = '3'
select * from table_name where b = '2' and a = '1' and c = '3'
select * from table_name where c = '3' and b = '2' and a = '1'
复制代码
固然 where 子句几个搜索条件顺序调换了，但不影响查询结果，这是由于 MySQL 的查询优化器会自动调解 where 子句的条件顺序以使用恰当的索引，所以 MySQL 不存在 where 子句的顺序问题而造成索引失效。
2-2、从左到右按顺序匹配
select * from table_name where a = '1'
select * from table_name where a = '1' and b = '2'
select * from table_name where a = '1' and b = '2' and c = '3'
select * from table_name where b = '1' and c = '3'
复制代码
这种缺失了最左边 a 字段的情况就是违反最左匹配原则的典型例子，结果就是没有用到索引（索引失效）。
由于缺失了最左边的字段，导致索引数据结构 B+ 树不知道第一步该查哪个节点，从而需要去全表扫描了。在建立搜索树的时间 a 就是第一个比力因子，必须要先根据 a 来搜索，进而才能今后继承查询 b 和 c。
2-4、缺失中心的字段
假如去掉中心的字段，生存最左边和右边的字段（就是我们说的索引字段不连续）：
select * from table_name where a = '1' and c = '3'
复制代码
结果就是只用到了 a 列的索引，而 b 列和 c 列都没有用到。
由于在这种情况下进行数据检索时，B+ 树可以用 a 来指定第一步的搜索方向，但由于下一个字段 b 的缺失，所以只能先把 a = 1 的数据主键 ID 都找出来，然后通过查到的主键 ID 回表查询相关行，再去匹配 c 值的数据了。固然，这至少把 a = 1 的数据筛选出来了，总比直接全表扫描很多多少了
2-5、匹配范围值
select * from table_name where a = 1 and b > 3 and c = 'mm';
复制代码
这种情况下，由于 a 是等值匹配，所以 B+ 树走完 a 索引之后 b 还是有序的，但走完 b 索引之后，由于 b 是范围匹配，所以此时 c 已经是无序的了，终极只使用了 (a, b) 两个索引（由于此时 c 就没法走索引，所以优化器只能根据 a, b 得到数据的主键 ID 回表查询，终极影响了执行服从）。
再比如下面的情况：
select * from table_name where a > 1 and b > 1
select * from table_name where a > 1 and a < 3 and b > 1;
复制代码
当多个列同时进行范围查找时，只有对索引最左边的谁人列进行范围查找才用到 B+ 树索引，也就是只有 a 用到索引，在 a > 1 和 1 < a < 3 的范围内 b 是无序的，所以 b 不能用索引，找到 a 的记载后，只能根据条件 b > 1 继承逐条过滤。
2-6、like 语句匹配问题
当索引列是字符型，并且使用了 like 语句进行含糊查询时，如果通配符 % 不出现在开头，则可以用到索引，否则将会违反了最左匹配原则，而不会使用索引，走的是全表扫描：
select * from table_name where a like 'As%'; //走索引查询
select * from table_name where a like '%As'; //全表查询
select * from table_name where a like '%As%'; //全表查询
当我们对查询的数据进行 order by 排序时，一般情况下，我们是先把数据记载加载到内存中，再用一些排序算法，比如快速排序，归并排序等在内存中对这些记载进行排序。但有时间查询的结果集太大不能在内存中进行排序时，需要临时借助磁盘空间存放中心结果，排序操作完成后再把排好序的结果返回客户端。Mysql 把这种在磁盘上进行排序的方式称为文件排序（Filesort）。
文件排序黑白常慢非常耗性能的，但如果 order by 子句用到了索引列，就有大概避免文件排序的问题：
select * from table_name order by a, b, c limit 10;
复制代码
由于 B+ 树索引本身就是按照上述规则排序的，正确来说就是：索引是有序的，所以得到的结果集已经排好序了，不消再进行额外的排序操作。
注意：order by 的子句后面的字段顺序也必须按照索引字段的顺序给出，不能颠倒顺序（MySQL 不会自动调解排序字段的顺序）。
下面这种就是由于颠倒顺序而没有使用索引的情况：
select * from table_name order by b, c, a limit 10;
复制代码
下面这种是用到部分索引的情况：
select * from table_name order by a limit 10;
select * from table_name order by a, b limit 10;
复制代码
下面这种情况，由于联合索引左边列为常量，后边的列排序可以用到索引：
select * from table_name where a =1 order by b, c limit 10;
复制代码
五、常见问题解答
比条件：test表中有c1,c2,c3这列，建立联合索引（c1,c2,c3）
1、 索引的掷中与查询sql中字段的顺序有关吗？
比如 select * from test where c1=2 and c2=5; 与 select * from test where c2=5 and c1=2？
答案：与查询的字段顺序无关，由于查询优化器会对搜索字段顺序跟索引字段顺序不划一的sql进行优化。
2、最左前缀原则如何明白，它的原理是什么？ 最左前缀原是指从索引的有效掷中来说，并不是触发。只要是索引，大概某个联合索引的一部分，就会被触发，详细掷中了那些索引字段，要根据key_len来做判断。 原理：
我们从上面的联合索引介绍中看到，它的排序方式是：每层节点先按照索引中的第1列排序。第1列值相等时，按第2列排序。第2列值相等时，按第3列排序 依次类推，所有列都相等时按照主键排序。
所以我们可以如许来分析：
对于联合索引中c1字段是放在最前面的，所以c1是完全有序的，但是c1不知情的条件下，对于c2字段就是无序的，没办法排序。因此只有当c1相同的时间，c2字段的索引排序才是完全有序的。
因此，在联合索引中你只有使用以下的规则的方式查询才会使用到索引：
c1
c1 ,c2
c1, c2, c3
我们再思考一下，select * from test where c2>=5 and c3=7; 这条sql语句会掷中索引么？
分析：这里使用了c2和c3这两个字段作为查询条件，但是没有使用c1字段，由于在c1不知情的条件下，对于c2是无序的。对于c2>=5的条件大概在很多的c1不同中都有符合条件的出现，所以就没有办法使用索引，这也是索引实现的缘故原由，一定要遵照「查找有序，充分使用索引的有序性」。
再比如 select * from test where c1>=5 and c2=9;
分析：这个查询语句中，c1列索引会被掷中，c2列却不会，只有c1列值相等时，才会按c2列排序。但是由于这里的c1>=5，那么c1列是不确定的，后面也就无法按照c2来排序，c2不会被掷中。
3、前导含糊查询为什么会导致索引失效？
比如 select * from test where c1 like '%d%';
字符串的查询是对字符串里面的字符一个一个的匹配，「如果字符串最左边为%表现一个不确定的字符串，那么是没办法使用到索引的有序性」。
但是如果修改为 ：where c1 like 'd%'；就可以使用索引，由于最左边的字符串是确定的，这种称为「匹配列前缀」。
补充说明：实际业务场景中联合索引的创建，「我们应该把辨认度比力高的字段放在前面，进步索引的掷中率，充分的使用索引」。
4、 如何办理数量占表记载比重较大，查询优化器放弃索引，直接全表扫描？ 通过限定查询条数来避免索引失效，比如 select * from test where c2=8 limit 10;
5、为什么MySQL的InnoDB引擎采用B+树而不是B树？
1）范围查询服从高
B+树在非叶子节点只存储键值信息，而不存储数据记载的详细位置，这使得B+树在进行范围查询时更加高效。范围查询通常涉及到一系列相邻的键值，B+树的叶子节点形成了一个有序链表，可以很方便地进行范围扫描。
2）更恰当磁盘存储
B+树的叶子节点形成了一个有序链表，便于顺序I/O，淘汰磁盘I/O的次数。这对于数据库来说非常告急，由于磁盘I/O是一个相对较慢的操作，通过淘汰I/O次数，可以进步查询性能。
3）更恰当范围查询
B+树中叶子节点使用双向指针相连接，形成一条双休有序链表，以及在叶子节点存储了所有关键字的信息，使得范围查询更为高效。而B树则需要在非叶子节点中存储所有关键字的信息，限定了非叶子节点的容量，不太恰当范围查询。
4）更恰当内存的使用
B+树的内部节点只存储键值信息，而不存储详细数据，这意味着在同样的内存空间下，B+树可以容纳更多的节点，进步了缓存掷中率，淘汰了内存占用。总体而言，B+树更恰当数据库索引的应用场景，特殊是对于范围查询和大数据集的情况。因此，InnoDB引擎选择了B+树作为其索引结构。
6、二级索引与null值的关系
值为NULL的二级索引记载被放在了B+树的最左边。这是由于InnoDB的设计中有如许的规定：
We define the SQL null to be the smallest possible value of a field.
翻译：我们把SQL中的NULL值以为是列中最小的值。 六、如何挑选索引
