IN子查询常因相关子查询或临时表溢出导致性能骤降，改用EXISTS或INNER JOIN可提速数倍至数十倍，但需确保语义等价、索引匹配及类型一致。
绝大多数情况下，把 IN 子查询改成 EXISTS 或 INNER JOIN 能直接提速几倍到几十倍——但改错一行，结果就可能出错或更慢。
为什么 IN 子查询会突然变慢
MySQL 不是“不支持 IN”，而是它的执行策略容易踩坑：外层每扫一行，就可能触发一次子查询（相关子查询）；或者先物化整个子查询结果到临时表，再逐行匹配。一旦子查询返回几千行，tmp_table_size 溢出，立刻转磁盘临时表，IO 拉满；更糟的是，优化器常因此放弃索引，EXPLAIN 里直接出现 type=ALL 和 key=NULL。
典型现象包括：EXPLAIN 的 Extra 列含 Using temporary 或 Using filesort；子查询本身毫秒级，套上 IN 后跳到秒级；监控中 Created_tmp_disk_tables 突增。
EXISTS 替换 IN 的实操要点
适用于“只判断存在性”的场景，比如 WHERE id IN (SELECT user_id FROM logs WHERE time > ...) 这类逻辑。
- 必须写成
WHERE EXISTS (SELECT 1 FROM logs l WHERE l.user_id = t1.id AND l.time > ...)—— 关联条件l.user_id = t1.id少一个字符，就退化为全表扫描 -
SELECT 1和SELECT *性能没区别，但绝不能写SELECT *，字段膨胀会干扰优化器选择 semi-join - 确保子查询中被关联的字段（如
logs.user_id）有索引，否则EXISTS和IN一样慢 -
NOT IN必须换为NOT EXISTS，否则子查询只要含任意NULL，整个条件恒为FALSE，查不到任何数据
INNER JOIN 替换 IN 的边界条件
适合需要取子查询其他字段、或后续要 GROUP BY/ORDER BY 的场景，比如你要同时拿到客户姓名和订单信息。
- 原写法：
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active') - 正确改写：
SELECT o.* FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' - 必须用
INNER JOIN，别用LEFT JOIN+WHERE c.id IS NOT NULL—— 优化器不一定能等价转换，仍可能走嵌套循环 - 如果子查询本身带
GROUP BY或ORDER BY，优先抽成派生表：FROM orders o INNER JOIN (SELECT DISTINCT user_id FROM logs WHERE ...) l ON o.user_id = l.user_id - JOIN 会放大结果行数（一对多），若业务只需去重 ID，得加
DISTINCT或直接改用EXISTS
容易被忽略的索引与类型陷阱
改写后没提速？90% 是卡在索引或类型上。
- 子查询的过滤字段（如
customers.status）必须有索引，否则JOIN前的customers扫描仍是全表 - 关联字段类型必须严格一致：如果
orders.customer_id是BIGINT，但子查询里用了字符串'123'，就会触发隐式转换，索引失效 - 联合索引顺序很重要：对
WHERE status = 'active' AND user_id = ?这类条件，建(status, user_id)比单列status索引高效得多 - 临时表方案里，
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)必须带主键或唯一索引，否则JOIN效率极低
真正难的不是语法替换，而是确认改写后的语义是否和原 IN 完全等价——尤其是空集、NULL、重复值这三处，业务逻辑稍有偏差，线上就丢数据。
