乐趣区

关于mysql:记一次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 剖析下:

拜访类型 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 也是一种形式。

退出移动版