嵌套子查询让SELECT变慢是因为外层每读一行就执行一次内层查询，导致N次重复扫描；应改用JOIN、EXISTS或临时表优化。
嵌套子查询为什么让 SELECT 变慢
因为数据库执行时，外层每读一行，就可能触发一次内层子查询——不是“查一次复用结果”，而是“查 N 次”。尤其当子查询含 JOIN 或未走索引的 WHERE，延迟直接随外层行数线性放大。
- 常见错误现象：
EXPLAIN显示type=ALL或rows值远超预期，Extra列出现Using temporary; Using filesort - 典型场景：报表类 SQL 中写
SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = u.id) AS order_cnt FROM users u - 参数差异：MySQL 5.7 默认不优化相关子查询；8.0+ 对部分模式支持
LATERAL，但需显式启用且语法不同 - 性能影响：10 万用户表 + 无索引的
orders.user_id，该语句可能从 200ms 拉长到 12s+
用 JOIN 重写替代大部分嵌套子查询
把“为每一行算一个值”转成“先算好所有值再关联”，数据库能一次性走索引、用哈希连接，避免重复扫描。
- 实操建议：把子查询单独拎出来做派生表或 CTE，再
LEFT JOIN回主表 - 示例（原写法）：
SELECT u.name, (SELECT SUM(amount) FROM payments p WHERE p.user_id = u.id) FROM users u - 改写后：
SELECT u.name, p.total FROM users u LEFT JOIN (SELECT user_id, SUM(amount) AS total FROM payments GROUP BY user_id) p ON u.id = p.user_id - 注意点：若子查询可能无匹配行（如用户没付款），必须用
LEFT JOIN，否则会丢数据；聚合函数要加GROUP BY，否则 MySQL 8.0+ 会报错
EXISTS 和 IN 的选择陷阱
二者语义不同，但很多人只图写得快，硬套导致全表扫描。关键看子查询是否需要返回值，还是只判断存在性。
-
EXISTS适合“是否存在满足条件的记录”，数据库可短路（找到第一个就停），通常更快；IN会先执行子查询生成结果集，再做哈希查找，若子查询返回NULL，整个条件变UNKNOWN - 错误写法：
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active')—— 若子查询里users.id有NULL，这行就永远不命中 - 更稳写法：
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active') - 兼容性提醒：PostgreSQL 对
IN子查询结果为空时行为更严格；MySQL 8.0+ 支持NOT IN转NOT EXISTS自动优化，但别依赖它
临时表 + 索引是压测时最可控的兜底方案
当子查询逻辑复杂（含多层 GROUP BY、窗口函数），又没法一次性重写，不如拆出来物化，人工控制执行时机和索引策略。
- 操作步骤：
CREATE TEMPORARY TABLE tmp_user_stats AS SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id→CREATE INDEX idx_user_id ON tmp_user_stats(user_id)→ 主查询JOIN tmp_user_stats - 为什么有效：临时表生命周期只在当前会话，不污染线上结构；索引可针对实际
JOIN字段建，比依赖优化器猜更可靠 - 容易踩的坑：忘记加索引，临时表反而比原子查询更慢；在事务中创建临时表，需确认隔离级别是否影响可见性（比如
READ COMMITTED下其他会话看不到） - 压测提示：用
SHOW PROFILE或performance_schema对比“子查询执行时间”和“临时表构建+JOIN 时间”，确认收益是否真实
嵌套子查询的性能问题，本质是执行计划失控，而不是语法本身有问题。真正难的不是改成 JOIN，而是在业务逻辑耦合紧、字段动态拼接、权限控制嵌套多的场景下，判断哪一层该提前物化、哪一层必须保留相关性——这时候看 EXPLAIN FORMAT=TREE 比背口诀管用。
