嵌套超过3层的子查询必须重构为cte或临时表，因其在数据量增大时易引发超时、解析器栈溢出及优化器放弃物化等问题；cte提供语义清晰、可复用的中间结果，而深层嵌套会导致同一子查询被重复执行。
嵌套超过3层的子查询必须重构，不是“能不能跑”，而是“下次数据量翻倍时会不会突然超时或报错”。解析器栈溢出、优化器放弃物化、执行计划反复扫描——这些问题在你看到慢查询之前就已埋下。
为什么WITH比多层子查询更可靠
CTE不是语法糖，它是向优化器发出的明确信号：“这段先算好，后面复用”。而深层嵌套会让MySQL 8.0、PostgreSQL等数据库默认放弃物化中间结果，导致同一子查询被外层每行重复执行。
- EXPLAIN中若出现
DEPENDENT SUBQUERY且rows值很大，就是典型信号 - PostgreSQL和SQL Server中CTE默认倾向物化；MySQL 8.0+需显式加
MATERIALIZED提示才强制物化 - 语义清晰：每层CTE起一个业务名（如
active_users、recent_orders），比(SELECT FROM (SELECT ))易读十倍
三层以上嵌套怎么拆成WITH
关键不是“全拆”，而是找语义断点：哪一层输出是后续多处依赖的稳定中间集？从最内层开始具名化。
- 原写法：
SELECT u.name FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE amount > (SELECT AVG(amount) FROM orders)) - 第一步：把
AVG(amount)提为avg_order，它不依赖外层，纯预计算 - 第二步：把订单过滤逻辑提为
high_value_orders，基于avg_order做CROSS JOIN而非子查询 - 第三步：主查询只
JOIN两个CTE，彻底消除嵌套层级
什么时候WITH不够用，得上临时表
CTE适合轻量、单语句、中间结果小于几万行的场景。一旦出现以下情况，必须换CREATE TEMPORARY TABLE：
- 同一CTE被主查询引用3次以上（CTE每次调用都重算）
- 中间结果含窗口函数或跨表
JOIN，且行数超5万 - 需要对中间字段建索引加速后续
JOIN（如ON temp_orders.user_id） - 调试困难：
CTE无法SELECT * FROM cte_name，但临时表可以
容易忽略的细节：索引和NULL陷阱
重构只是第一步。没配好索引或掉进NULL坑里，性能照样崩。
- 所有
JOIN字段（如user_id、order_date）必须有索引，否则临时表JOIN变成全表扫描 -
WHERE col IN (SELECT id FROM t)换成JOIN前，必须确认子查询结果不含NULL，否则JOIN会自动过滤，结果不等价 - 临时表建完立刻加索引，不要等
JOIN时才发现type=ALL
真正卡住人的从来不是语法会不会写，而是改完之后发现EXPLAIN里还是DEPENDENT SUBQUERY，或者临时表没索引导致JOIN耗时暴涨十倍——这些地方没有银弹，只有逐层验证。
