子查询性能问题本质是执行路径失控而非语法错误：相关子查询每行重算、in默认嵌套循环+临时表物化、not in遇null返回空；应改用join、派生表预计算、not exists替代，并确保索引覆盖。
子查询在数据量大时超时，基本不是“写法错”，而是执行模型被数据库引擎拖垮了——相关子查询每行都重跑一次、IN生成临时表、NOT IN遇到NULL直接返回空结果，这些都不是语法问题，是执行路径失控。
WHERE里用IN子查询，为什么一过50万行就卡死？
本质是MySQL（尤其5.7及之前）对IN子查询默认走嵌套循环+临时表物化。当子查询结果集超过tmp_table_size（默认16MB），就会落地磁盘，IO爆炸；更糟的是，如果外层主表有100万行，它会为每一行重复执行子查询逻辑，等效扫描行数 = 主表行数 × 子查询平均扫描行数。
- 别硬扛：
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE vip=1)在users表百万级时，EXPLAIN会显示type=ALL且rows巨大 - 先确认子查询是否能走索引：检查
users(vip)有没有单列索引，或(vip, id)联合索引（覆盖索引避免回表） - 立刻改写：用
JOIN替代，让优化器有机会选哈希连接或排序合并
相关子查询（correlated subquery）怎么改才不触发N×M扫描？
像WHERE price > (SELECT AVG(price) FROM products p2 WHERE p2.category = p.category)这种写法，数据库无法提前物化子查询结果，只能在外层每行p上重新算一次平均值。哪怕category只有10个值，它也算了100万次，而不是10次。
- 拆成两步：先把各category的平均价算出来存成派生表，再
JOIN回主表 - 示例：
SELECT p.* FROM products p JOIN (SELECT category, AVG(price) avg_price FROM products GROUP BY category) cat_avg ON p.category = cat_avg.category WHERE p.price > cat_avg.avg_price - 注意：派生表必须带别名（如
cat_avg），否则MySQL 5.7+会报错 - 如果category维度高（比如上千个），考虑加
WHERE category IN (...)提前过滤，别让派生表扫全表
NOT IN和NOT EXISTS哪个更稳？
NOT IN在子查询结果含NULL时必然返回空集——这是SQL三值逻辑的坑，不是性能问题，但会让业务查不到数据，还看不出错在哪。而NOT EXISTS不受NULL影响，且现代MySQL对它的优化更好（常转成反向半连接）。
- 绝对避开：
WHERE id NOT IN (SELECT user_id FROM logins WHERE time > ...)——只要logins里任意一行user_id为NULL，整个结果就是空 - 换成：
WHERE NOT EXISTS (SELECT 1 FROM logins l WHERE l.user_id = u.id AND l.time > ...) - 确保
logins(user_id, time)有联合索引，否则NOT EXISTS内部仍会全表扫 - 大数据量下，
NOT EXISTS比LEFT JOIN ... IS NULL略快，因为前者可短路（找到匹配就停），后者必须完成全部连接
真正卡住的从来不是子查询本身，而是你没告诉数据库“这部分逻辑可以一次性算完”。所有改写的核心，都是把“每行都问一遍”变成“先算好答案，再批量匹配”。索引、执行计划、NULL陷阱，三者漏掉任何一个，优化就白做。
