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

站长资源 2024/11/24 佚名

2 0 1

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的联合索引,MySQL怎么优化

广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！

评论“一次Mysql使用IN大数据量的优化记录”

暂无评论...

《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒经典版》的玩家都可以获得奖励。

更新日志

2024年11月24日

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

基于JPQL实现纯SQL语句方法详解

MySQL复制表的三种方式(小结)

评论“一次Mysql使用IN大数据量的优化记录”

《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线

更新日志

友情链接