IN子查询在大数据量下性能差因临时表无索引致全表扫描；优先用JOIN替代，确保关联字段有索引；存在性判断选EXISTS；避免相关子查询，改用聚合后JOIN；务必EXPLAIN验证执行计划。
IN 子查询在百万级以上数据量下极易拖慢查询，不是语法错，而是执行机制本身有缺陷：MySQL 会为子查询结果建临时表，且该表无索引，外层每行都可能触发全表扫描。
用 JOIN 替代 IN 子查询最直接有效
这是多数场景下优先级最高的改写方式，尤其当子查询条件可转为等值关联时。
-
IN写法（慢）：SELECT * FROM orders WHERE user_id IN (SELECT user_id FROM users WHERE vip_level > 3) -
JOIN改写（快）：SELECT o.* FROM orders o JOIN users u ON o.user_id = u.user_id WHERE u.vip_level > 3 - 关键点：确保
users.user_id有主键或唯一索引，users.vip_level在复合索引中靠前（如INDEX(vip_level, user_id)） - 注意
LEFT JOIN ... IS NULL才等价于NOT IN，直接用JOIN是交集语义，别混淆
EXISTS 比 IN 更适合存在性判断
当子查询只关心“是否存在匹配行”，而非具体值时，EXISTS 通常比 IN 更轻量，尤其子查询结果集大或含 NULL 时。
-
IN遇到NULL会整体返回空结果（SQL 标准行为），而EXISTS不受干扰 - 优化器对
EXISTS更倾向使用半连接（semi-join），可提前终止内层扫描 - 示例：
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM payments p WHERE p.order_id = o.id AND p.status = 'success')，只要找到一条就停，不穷举 - 务必在
p.order_id上建索引，否则EXISTS也退化为全表扫描
避免相关子查询（correlated subquery）
这是性能杀手——外层查多少行，子查询就执行多少次。哪怕子查询本身很快，乘上 N 倍后也扛不住。
- 典型反例：
SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = u.id) AS cnt FROM users u - 正确解法：先聚合再
JOIN，SELECT u.name, COALESCE(o.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id - MySQL 8.0+ 对派生表（derived table）支持物化缓存，但老版本仍建议显式写出聚合子查询并加索引
- 如果必须用相关子查询，请确认外层结果集极小（比如只查 10 行以内），否则一律重构
检查执行计划，别信“看起来一样”
同一语义的 SQL，执行计划可能天差地别。光看语句写得“简洁”没用，EXPLAIN 才是真相。
- 重点关注
type字段：出现ALL或index就意味着扫描了整张表或整条索引 - 留意
Extra列：Using temporary表示建了临时表，Using filesort表示排序未走索引，Using join buffer可能是哈希连接启用信号 - 对比改写前后
rows值：下降一个数量级才算有效优化 - 特别注意：MySQL 5.7 默认开启半连接优化，但若子查询含
ORDER BY或LIMIT，优化器可能自动禁用 semi-join，这时需手动干预
真正卡住性能的往往不是子查询语法本身，而是它掩盖了索引缺失、数据倾斜或执行路径失控的问题。每次优化前，先跑一遍 EXPLAIN，盯着 rows 和 Extra 看，比背口诀管用得多。
