登录
首页 >  数据库 >  MySQL

记一次Mysql使用IN大数据量的优化

来源:SegmentFault

时间:2023-01-10 14:28:51 318浏览 收藏

在IT行业这个发展更新速度很快的行业,只有不停止的学习,才不会被行业所淘汰。如果你是数据库学习者,那么本文《记一次Mysql使用IN大数据量的优化》就很适合你!本篇内容主要包括记一次Mysql使用IN大数据量的优化,希望对大家的知识积累有所帮助,助力实战开发!

mysql版本号是5.7.28,表A有390W条记录,使用InnoDB引擎,其中varchar类型字段mac已建立索引,索引方法为B-tree。B表仅有5000+条记录。

有一条SQL指令是这样写的:

SELECT * FROM A WHERE mac IN("aa:aa:aa:aa:aa:aa","bb:bb:bb:bb:bb:b",...此外省略900+条)

通过查询出来的结果耗时294.428s。没错,将近5分钟。

使用EXPLAIN分析下:

B9208618-FB53-4ad4-AF6F-A938C7D67705.png

访问类型type是range,且已命中索引,rows行也只有587776,可为什么查询耗时要这么久?

mac的索引方法使用了B-tree,那对比下它与HASH的区别,简单地总结下:B-tree索引可以用于进行 =,>,>=,

既然调整索引方法并不能明显地提升语句的查询性能,那只能从语句本身中进行处理。其实明眼人刚开始一看就知道,SELECT * 是很耗性能的,那我们只查业务上需要的字段,语句调整为:

SELECT id,mileage FROM A WHERE mac IN("aa:aa:aa:aa:aa:aa","bb:bb:bb:bb:bb:b",...此外省略900+条)

耗时并没有明显的提升。

竟然IN的方式这么难优化,是不是可以放弃使用LEFT JOIN呢?语句调整为:

SELECT a.id,a.mileage FROM A a LEFT JOIN B b ON b.mac = a.mac WHERE b.create_time >= '2020-01-01'

耗时超过5分钟,放弃。

我们知道,在条件量少的情况,EXISTS和IN的效果没有显示的差别。但条件多的时候,IN要比EXISTS的效率也高,来试下EXISTS:

SELECT id,mileage FROM A a WHERE EXISTS(SELECT mac FROM B WHERE create_time >= '2020-01-01' AND mac = a.mac)

耗时也是超过5分钟,IN的效率确实要比EXISTS高,放弃。

所以最后的结论是,如果IN后接大数据量的String,要慎重。

在项目中我把mac作为唯一标识建立与id的对应表,在A表使用mac_id代替mac,查询的时候使用IN(1,2,3...)。效率会提高一些。当前使用NoSQL也是一种方式。

以上就是《记一次Mysql使用IN大数据量的优化》的详细内容,更多关于mysql的资料请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表