时间:2021-05-23
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分析下:
访问类型type是range,且已命中索引,rows行也只有587776,可为什么查询耗时要这么久?
mac的索引方法使用了B-tree,那对比下它与HASH的区别,简单地总结下:B-tree索引可以用于进行 =,>,>=,<,<=和between的计算,而HASH只能进行等值运算,不能进行范围查找。那IN是等值运算,两种索引方法都适用。即然这样,把mac的索引方法修改为HASH,同样的查询耗时为。
既然调整索引方法并不能明显地提升语句的查询性能,那只能从语句本身中进行处理。其实明眼人刚开始一看就知道,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使用IN大数据量优化内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
正儿八经mysql优化!mysql数据量少,优化没必要,数据量大,优化少不了,不优化一个查询10秒,优化得当,同样查询10毫秒。这是多么痛的领悟!mysql优化
目录一、前言二、JDBC实现流式查询三、性能测试3.1.测试大数据量普通查询3.2.测试大数据量流式查询3.3.测试小数据量普通查询3.4.测试小数据量流式查询
本文实例分析了php查询mysql大量数据造成内存不足的解决方法。分享给大家供大家参考。具体分析如下:一、问题使用php查询mysql大数据量的时候,程序尚未执
大数据测试包含如下: 1、实时大数据量。模拟用户工作时的实时大数据量,主要目的是测试用户较多或者某些业务产生较大数据量时,系统能否稳定地运行。 2、极限状态
优化数据库的方法有: 1、选取最适用的字段属性,MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在