mysql 真假,MYSQL 索引真真假假2-CSDN博客

最近会经常的标注(文章的作者没变还是 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来说还是适用的一句话。