用JOIN替代IN子查询通常显著提速，因其避免了重复执行或临时表开销；需确保关联字段有索引，并用INNER JOIN替代IN、LEFT JOIN加IS NULL替代NOT IN。
直接结论：用 JOIN 替代 IN 子查询，绝大多数情况下能显著提速，尤其当子查询结果集较大或外层表数据量高时。
为什么 IN 子查询容易变慢
MySQL 5.7 及更早版本对 IN 子查询的执行策略较保守：外层每扫一行，就触发一次子查询（相关子查询），或先生成临时表再做哈希匹配（非相关子查询）。一旦子查询涉及 DISTINCT、ORDER BY 或大结果集，就会出现全表扫描、磁盘临时表、索引失效等问题。典型表现是 EXPLAIN 中出现 dependent subquery 或 Using temporary; Using filesort。
-
NOT IN还有隐式陷阱：只要子查询结果含任意NULL，整个条件恒为FALSE，导致查不到任何数据 - 当
IN列表元素超过eq_range_index_dive_limit（默认 200），优化器会跳过索引深度分析，改用粗略统计，可能选错执行计划 - 子查询中若未在关联字段上建索引（如
user_logins.user_id），JOIN也救不了——索引仍是前提
怎么把 IN 子查询安全改成 JOIN
核心原则：把“筛选存在性”逻辑，转为“连接后过滤”。不追求语法等价，而追求语义等价（返回相同行）。
- 原写法：
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active') - 改写后：
SELECT o.* FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' - 注意
JOIN类型：用INNER JOIN替代IN；用LEFT JOIN ... WHERE xxx IS NULL替代NOT IN - 务必检查
ON条件字段是否都有索引——orders.customer_id和customers.id都要索引，否则JOIN仍走嵌套循环
JOIN 改写后性能差异的关键点
改写不是一劳永逸，效果取决于执行计划是否真正切换到哈希连接或索引驱动的嵌套循环。
- 看
EXPLAIN的type字段：从ALL或index变成ref或eq_ref才算生效 - 如果子查询本身很重（比如带
GROUP BY+ 多表JOIN），先把它抽成派生表（FROM (...) AS derived），再和主表JOIN，避免重复计算 - 当子查询结果极小（IN 可能比
JOIN更快——MySQL 对小集合做了专门优化，此时强行改写反而画蛇添足 -
JOIN会放大结果集行数（比如一对多），若业务只需去重 ID，记得加DISTINCT或用EXISTS替代
容易被忽略的边界情况
实际改写时，最容易翻车的是语义细节。这些不处理，结果可能出错：
-
IN子查询返回NULL→ 整个条件为UNKNOWN→ 行被过滤掉；JOIN则天然排除NULL关联，行为一致。但若子查询本意是“包含NULL”，就得额外补逻辑 - 原
IN子查询若含重复值（如多个相同customer_id），IN自动去重；JOIN不去重，可能导致主表同一行出现多次——需加DISTINCT或改用EXISTS - 当子查询有
LIMIT（如取最新 10 条记录），JOIN无法直接表达——此时应优先考虑派生表 +LIMIT，再JOIN
