生产慢查询记录：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消息（按业务实际需求）