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），这样的说法可不是对的哦
