这篇文章给大家介绍如何看待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 employee 香港云主机s where first_name = ‘Kyoichi’ and last_name = ‘Maliniak’ （使用单独first_name 索引）从以上的值上面我们就可以很清楚的看到Sending data 经过在细致的查看，具体的cost 的主要发生在 sending data 这个阶段，另外一个位置虽然消耗的不同可以在微妙这个等级，但确实system lock 这个东西，比较起来， 复合索引和intersect 不相伯仲。所以这次对比中，可以说复合索引获胜。故事就到此结束了？ Nein Nein Nein (我很喜欢Tomas ,这个梗你懂伐)我们继续,建立一个indexIX_first_name_last_name_hire_date因为我们要用ORDER BY我们可以通过图来清晰的看出，我们的查询没有走 filesort 直接走了索引，这样的效率，自然比走filesort 的要好的多，尤其数据量较大的情况。但 但 但，重要的事情的说三遍，这个查询其实和上边雷同，但不一样的是你的查询条件变为了 LIKE 虽然也走了索引，但最后并未走我们的 using index condition only, 还是带了 filesortWHY
我们分析一下，走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 索引就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
本篇文章给大家分享的是有关mybatis中怎么实现foreach循环， 香港云主机小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。以上就是mybatis中怎么实现foreach循环，小编相信有部分知识…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
