IN子查询在大多数实际场景下不如JOIN快，因其易触发DEPENDENT SUBQUERY或Using temporary，而JOIN可走索引嵌套循环或哈希连接；当EXPLAIN出现dependent subquery、Using temporary或语句随外层行数线性变慢时，应改写为JOIN，并确保加DISTINCT、索引到位且ON/WHERE条件位置正确。
IN 子查询在大多数实际场景下，不如 JOIN 快——这不是经验之谈，而是 MySQL 优化器执行路径决定的。当子查询结果集超过几百行，或外层表数据量稍大，IN 很可能触发 Using temporary 或反复执行，而 JOIN 能走索引嵌套循环甚至哈希连接。
什么时候必须改写 IN 子查询为 JOIN
看到这些信号，就该动手了：
-
EXPLAIN输出中出现dependent subquery或Using temporary; Using filesort - 子查询本身不慢，但整条语句随外层行数线性变慢（比如外层 10 万行，耗时 10 秒）
- 子查询只查单列（如
SELECT id FROM customers WHERE status = 'active'），且和外层有明确关联字段（如orders.customer_id） - 子查询不含
ORDER BY + LIMIT、无聚合、无跨多层嵌套引用
IN 改 INNER JOIN 的实操要点
核心不是语法替换，而是保语义、控膨胀、压索引：
- 原语句：
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE city = 'Shanghai') - 正确改写：
SELECT DISTINCT o.* FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.city = 'Shanghai' - 必须加
DISTINCT或GROUP BY o.id：否则一个上海客户有多笔订单，orders行会重复输出 -
customers.id和orders.customer_id都要有索引；更优是建联合索引customers(city, id)，让WHERE c.city = 'Shanghai'直接走索引覆盖 - 别用
LEFT JOIN+WHERE c.id IS NOT NULL替代IN——语义等价但执行计划更难优化，且易漏掉索引下推机会
NOT IN 改 LEFT JOIN 的坑在哪
NOT IN 看似简单，但改错一行就全错：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 错误写法：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.city != 'Shanghai'→ 实际变成INNER JOIN，且逻辑完全不对 - 正确写法：
LEFT JOIN customers c ON o.customer_id = c.id AND c.city = 'Shanghai' WHERE c.id IS NULL - 关键点：
c.city = 'Shanghai'必须放在ON子句里，不是WHERE；否则 MySQL 先做全量LEFT JOIN，再过滤，IS NULL条件失效 - 如果
customers.id允许为NULL，还要补上AND c.id IS NOT NULL，否则IS NULL判断会误判
标量子查询（SELECT (subquery)）怎么安全转 JOIN
这类子查询常用于取关联表的单个字段，最容易忽略的是 NULL 和重复匹配：
- 原语句：
SELECT id, name, (SELECT phone FROM contacts WHERE user_id = users.id LIMIT 1) AS phone FROM users - 直接
LEFT JOIN contacts会因一对多导致主表行重复，不能直接用 - 稳妥做法：先聚合子表，再
LEFT JOIN：SELECT u.id, u.name, c.phone FROM users u LEFT JOIN (SELECT user_id, MAX(phone) AS phone FROM contacts GROUP BY user_id) c ON u.id = c.user_id - 如果子查询含复杂条件（如
WHERE status = 'valid'），聚合派生表里也要带上，确保逻辑一致 - 别依赖
LIMIT 1——MySQL 不保证返回哪一行，MAX()或ANY_VALUE()（配合sql_mode）才可控
真正卡住性能的，往往不是子查询语法本身，而是改写时没确认索引是否生效、没处理好一对多引发的行膨胀、或把本该在 ON 里的条件错塞进 WHERE。每次改完，务必跑一遍 EXPLAIN，盯着 type 是不是从 ALL 变成了 ref 或 eq_ref。
