最近会经常的标注（文章的作者没变 还是 Austin 但因为赞赏账号的原因，所以必须署名 carol11）

MYSQL 的索引记得上个月写过一篇文章，好像反响还不错，同学们喜闻乐见的东西就继续。

我们先看一个表

select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak';

按照一般思路，根据数据量我们决定是不是要建立索引，而建立索引针对这样的情况，到底那种索引更好。

我们来做一个实验，建立为这个一个查询我们建立三个索引

分别是 first_name    last_name   first_name_lat_name

可以看到的是查询执行器选择了 first_name_last_name 这样的联合索引

为什么，我们带着问题继续

我这边将这个联合索引删除

我们可以看到结果是什么，结果是走的一种叫 intersect 方式的索引，

我们还继续带着问题看（不要着急，你的问题会在最下面来进行总结和揭晓）

我们删除IX_LAST_NAME 这个索引，然后在继续进行查询

OK ，到此，我觉得可以小结一下了，

问题1 ，那种索引更好

问题2，intersect   索引好还是联合索引方式好

问题3，你为什么删除了 LAST_NAME 而不删除 FIRST_NAME

带着这三个问题，我们继续开始旅程

在提那种索引更好的情况下，其实我们应该知道这些索引到底给查询带来了什么效应。

下面的数字体现了查询的cost 值

 0.00081800 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （复合索引）

0.00145100 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （intersect 索引）

0.00250350 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （使用单独first_name 索引）

从以上的值上面我们就可以很清楚的看到

Sending data  经过在细致的查看，具体的cost 的主要发生在 sending data 这个阶段，另外一个位置虽然消耗的不同可以在微妙这个等级，但确实system lock 这个东西，比较起来， 复合索引和intersect 不相伯仲。

所以这次对比中，可以说复合索引获胜。

故事就到此结束了？  Nein  Nein  Nein  (我很喜欢Tomas ,这个梗你懂伐)

我们继续,建立一个index   IX_first_name_last_name_hire_date

因为我们要用ORDER BY

我们可以通过图来清晰的看出，我们的查询没有走 filesort 直接走了索引，这样的效率，自然比走filesort 的要好的多，尤其数据量较大的情况。

但 但 但，重要的事情的说三遍，这个查询其实和上边雷同，但不一样的是你的查询条件变为了 LIKE  虽然也走了索引，但最后并未走我们的 using index condition only, 还是带了 filesort

WHY

我们分析一下，走using index condition only 中的 type  是  ref ,而 走filesort的 却是， type 是 range ， 我们看一下profiling， 头一个是range 后面是等值查询，我们可以清晰的看出，如果走了range 则要多一个步骤，creating sort index ,并且消耗不低可以说占了整体查询消耗的90%，所以那句能不排序就不排序，在MYSQL 5.7来说还是适用的一句话。

另外本次要戳穿的假象就是，即使你创建了索引，并且也考虑了order by适用的字段加入索引，在某些查询时，ASC时他也要 filesort ，而不是向网上有的人说的，把ORDER BY 的字段添加到索引，就完全可以不在FILESORT（ASC），这样的说法可不是对的哦