嵌套超过3层必须立即重构，因mysql解析栈可能崩溃、postgresql/sql server优化器放弃代价估算导致执行计划失控；dependent subquery且rows值大是典型信号，需用cte或临时表物化中间结果并确保join字段有索引。
嵌套超过3层就该重构，不是等报错或变慢才动手——MySQL解析栈可能直接崩，PostgreSQL/SQL Server优化器会放弃代价估算，结果不可控。
EXPLAIN里出现DEPENDENT SUBQUERY且rows值很大
这是最直观的信号：外层每扫一行，内层子查询就重执行一次。比如外层10万行，内层又没索引，实际执行就是10万次全表扫描。
- 立刻检查
EXPLAIN FORMAT=TREE或EXPLAIN ANALYZE，确认是否真有嵌套子查询节点 - 重点看
type列：若为DEPENDENT SUBQUERY且rows值远超预期，说明未物化 - 别只盯着“能跑”，要查
Extra字段是否含Using temporary或Using filesort——这往往是深层嵌套拖垮性能的副产品
用WITH CTE提前物化中间结果
CTE不是语法糖，它是向优化器发出“先算好、后面复用”的明确提示。但效果因数据库而异，不能无脑套用。
- PostgreSQL和SQL Server默认倾向物化；MySQL 8.0+需显式加
MATERIALIZED提示（如WITH MATERIALIZED avg_order AS (...)） - 必须给每个CTE显式声明字段名，禁用
SELECT *——列序变化会导致字段错位 - 只在中间结果被引用≥2次，或需参数化（如传入
@start_date）时才值得用CTE；否则直接写JOIN更轻量
CREATE TEMPORARY TABLE比CTE更可控
当某层子查询返回数万行以上，或被多次引用、含窗口函数、需建索引时，临时表是唯一稳妥选择。
- 执行
CREATE TEMPORARY TABLE tmp_active_users AS SELECT user_id FROM events WHERE ...后，立刻建索引：CREATE INDEX idx_user_id ON tmp_active_users(user_id) - 临时表可直接
SELECT * FROM tmp_active_users调试，CTE做不到 - 注意生命周期：临时表只在当前会话有效，不用手动
DROP；但若同一语句中多次引用，它不会重复计算——CTE每次引用都重算
视图嵌套超3层必须拆，别指望WITH能救
视图嵌套不是“逻辑深”，是优化器主动放弃治疗。MySQL 5.7前不合并视图，SQL Server/PostgreSQL三层后常选错连接顺序。
- 禁止在CTE里写
ORDER BY或LIMIT——这会强制物化并截断结果，后续无法复用 - 避免多个CTE交叉引用（A依赖B，B又依赖A），破坏线性执行流
- 真正该建物化视图的场景很窄：中间结果24小时内被≥5个不同查询调用，且基表更新≤每小时1次
最容易被忽略的点：所有JOIN字段必须有索引，哪怕用了CTE或临时表——没索引的JOIN照样全表扫描；NULL传播也得手动处理，IN (SELECT ...)遇到NULL就整个条件失效，换成EXISTS或JOIN加IS NOT NULL校验。
