相关子查询会触发N次全表扫描，因其每行都需重新执行子查询；主表返回8万行则子查询执行8万次，总开销线性爆炸，MySQL 5.7及PG 12前默认nested-loop策略且不自动改写为JOIN。
嵌套子查询里每出现一次未关联的 SELECT * FROM big_table，就可能多扫一遍表——不是“可能”，是大概率发生。
为什么相关子查询会触发 N 次全表扫描
只要子查询里引用了外层表字段，比如 WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept_id = e1.dept_id)，数据库就必须为 e1 的每一行重新执行一次子查询。如果主表返回 8 万行，子查询就真跑 8 万次。
- 哪怕子查询本身能走索引，总 I/O 和 CPU 开销也呈线性爆炸
- MySQL 5.7、PostgreSQL 12 之前默认采用 nested-loop 执行策略，不会自动改写为 JOIN
- EXPLAIN 中看到大量
DEPENDENT SUBQUERY或SELECT TYPE: DEPENDENT SUBQUERY就是明确信号
用 WITH（CTE）替代多层 FROM (SELECT) 套娃
三层子查询各自 FROM orders，数据库很可能扫三遍表；而 CTE 只需执行一次，后续可复用结果。
- 错：
SELECT city, AVG(price) FROM (SELECT * FROM (SELECT * FROM orders WHERE price BETWEEN 0 AND 5000) t1 JOIN users u ON t1.user_id = u.id) t2 GROUP BY city—— orders 被读三次 - 对：
WITH clean_orders AS (SELECT * FROM orders WHERE price BETWEEN 0 AND 5000) SELECT city, AVG(price) FROM clean_orders JOIN users u ON clean_orders.user_id = u.id GROUP BY city - 注意：PostgreSQL/SQL Server 默认不物化 CTE；MySQL 8.0 需确认
optimizer_switch='cte_materialization=off'，否则反而更慢
把过滤条件尽量下推到最内层子查询
外层 WHERE 条件无法下推时，优化器只能先算出全部中间结果，再过滤——等于白扫。
- 避免写成
FROM (SELECT * FROM orders) o WHERE o.status = 'paid'，应直接写FROM (SELECT order_id, user_id, amount FROM orders WHERE status = 'paid') o - JOIN 字段、GROUP BY 字段必须有索引，否则下推后仍会全表扫描
- Oracle 中可用
/*+ MATERIALIZE */强制物化并复用；MySQL 8.0+ 可用WITH ... AS MATERIALIZED（需开启对应开关）
IN/EXISTS 替换前先看子查询是否走索引
WHERE id IN (SELECT user_id FROM users WHERE status = 'active') 看似合理，但若 users.status 没索引，MySQL 就会为外层每行都扫一遍 users 表。
- 先单独运行子查询，用
EXPLAIN确认是否走了INDEX RANGE SCAN，而非TABLE ACCESS FULL - 优先用
EXISTS：WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active')，语义清晰且 MySQL 对其路径选择更稳定 - 绝对避免
NOT IN (SELECT ...)，一旦子查询含NULL，整个结果集为空，优化器直接放弃索引
真正危险的不是“写了嵌套”，而是嵌套里藏着没索引的过滤、没下推的条件、和被忽略的执行计划细节。每次加一层子查询，都要用 EXPLAIN 看一眼 rows 和 type——别等上线后查 SHOW PROCESSLIST 发现全是 Sending data 才反应过来。
