如何看待MYSQL索引
这篇文章给大家介绍如何看待MySQL 索引,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
创新互联公司长期为上千余家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为苍南企业提供专业的做网站、成都网站建设,苍南网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。
我们先看一个表
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),这样的说法可不是对的哦
关于如何看待MYSQL 索引就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
本文标题:如何看待MYSQL索引
链接分享:http://scjbc.cn/article/igcdcc.html