生产慢查询记录:MySQL IN 子查询导致的慢查询
Posted 北亮bl
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了生产慢查询记录:MySQL IN 子查询导致的慢查询相关的知识,希望对你有一定的参考价值。
嗯,先说结论:
mysql的 in subquery 会导致全表扫描,并不会走索引,即使是用主键id in (子查询)也一样,比如:
SELECT id FROM Activity WHERE Id IN (SELECT 1 WHERE 1=1)
SELECT id FROM Activity WHERE Id IN (SELECT 1 WHERE 1=0)
参考官方对 IN(子查询) 的说明,里面说:先执行外层查询,再匹配子查询生成的数据
MySQL evaluates queries “from outside to inside.” That is, it first obtains the value of the outer expression outer_expr, and then runs the subquery and captures the rows that it produces.
所以,不要使用WHERE field IN (子查询)这种写法。
注:WHERE field IN (11, 22, 33)这种写法是没问题的,可以正常使用索引。
解决方案:
1、尽量不用子查询,改用EXISTS(这个不是本文的问题所在)
2、程序代码中,如果数组为空 或 id<=0,不要让它去执行数据库查询
下面是正文:
当天发布后,过了一段时间,生产环境监控开始告警,有些站点监控的响应都要3秒以上,再过了一会,MySQL的CPU开始告警,
直接连上服务器用 SHOW FULL PROCESSLIST
查看,发现大量的如下语句,都处于lock wait状态:
SELECT * FROM Activity WHERE Id IN (SELECT NULL WHERE 1 = 0)
接着用EXPLAIN分析上述语句,果然是全表扫描(虽然表比较小,但是查询量太大了)
此时,当然是立即安排业务同学回滚,确保业务正常了。
然后查找为什么会有这么奇怪的SQL,发现是Dapper.SqlMapper.Query
方法,如果传入参数为空,就会生成这种带子查询的SQL,太坑了。
顺手拿Spring JPA测试了一下,同样的空数组,JPA生成的SQL如下:
SELECT * FROM Activity WHERE Id IN (NULL)
这种执行是没问题的,不会扫表:
同时验证了一下没有索引的字段:
SELECT * FROM Activity WHERE CreationTime IN (NULL)
发现也是全表扫描,虽然 CreationTime 字段定义为 NOT NULL,并没有用:
所以,看起来要增加一个开发的最佳实践要求了,必须先做判断:当数组为空时,不执行数据库查询:
if (idList == null || idList.Count == 0)
return new List<Activity>();
const string sql = "select * from Activity where Id in @Ids";
return Query(sql, new Ids = idList);
引申出的其它最佳实践:
- id <= 0 不执行数据库查询
- 相关参数为空或默认值时,不发起http请求
- 没有操作或操作失败时,不发送MQ消息(按业务实际需求)
以上是关于生产慢查询记录:MySQL IN 子查询导致的慢查询的主要内容,如果未能解决你的问题,请参考以下文章