一次Mysql使用IN大数据量的优化记录
#代码知识 发布时间： 2026-01-12
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 >= '2025-01-01'
耗时超过5分钟，放弃。
我们知道，在条件量少的情况，EXISTS和IN的效果没有显示的差别。但条件多的时候，IN要比EXISTS的效率也高，来试下EXISTS：
SELECT id,mileage FROM A a WHERE EXISTS(SELECT mac FROM B WHERE create_time >= '2025-01-01' AND mac = a.mac)
耗时也是超过5分钟，IN的效率确实要比EXISTS高，放弃。
所以最后的结论是，如果IN后接大数据量的String，要慎重。
在项目中我把mac作为唯一标识建立与id的对应表，在A表使用mac_id代替mac，查询的时候使用IN(1,2,3...)。效率会提高一些。当前使用NoSQL也是一种方式。
总结
代码知识SEO上一篇 : C# 中 System.Index 结构体和 Hat 运算符(^)的使用示例
下一篇 : jackson设置返回null为空字符串的操作
-
SEO外包最佳选择国内专业的白帽SEO机构，熟知搜索算法，各行业企业站优化策略！
SEO公司
-
可定制SEO优化套餐基于整站优化与品牌搜索展现，定制个性化营销推广方案！
SEO套餐
-
SEO入门教程多年积累SEO实战案例，从新手到专家，从入门到精通，海量的SEO学习资料！
SEO教程
-
SEO项目资源高质量SEO项目资源，稀缺性外链，优质文案代写，老域名提权，云主机相关配置折扣！
SEO资源
-
SEO快速建站快速搭建符合搜索引擎友好的企业网站，协助备案，域名选择，服务器配置等相关服务！
SEO建站
-
快速搜索引擎优化建议没有任何SEO机构，可以承诺搜索引擎排名的具体位置，如果有，那么请您多注意！专业的SEO机构，一般情况下只能确保目标关键词进入到首页或者前几页，如果您有相关问题，欢迎咨询！
