CTE嵌套本身不导致解析器性能下降，真正问题是优化器在3层以上结构性退化：跳过代价估算、条件未下推、行数预估偏差超3个数量级，且交叉引用、中间排序、SELECT *等用法会强制全物化，MySQL 8.0.23前更因默认重执行引发N次IO放大。
CTE嵌套本身不直接导致“解析器性能下降”，真正出问题的是优化器（optimizer），不是解析器（parser）。解析器只负责语法检查和生成抽象语法树（AST），毫秒级完成；慢在后续的查询重写、代价估算和执行计划生成阶段。三层以上CTE嵌套会让主流数据库（PostgreSQL、SQL Server、MySQL 8.0+）的优化器结构性退化——这不是配置能调的，是内核对嵌套深度的硬性限制。
为什么优化器会在3层后放弃代价估算
数据库内核为避免组合爆炸，对嵌套结构设了安全阈值。超过3层时，优化器跳过行数估算、条件下推、连接顺序重排等关键步骤，直接按“最坏情况”生成计划：
-
EstimatedRows和ActualRows差距常超3个数量级（比如预估120行，实际扫描85万行），说明条件根本没下推到底层基表 - PostgreSQL 中高频出现
MATERIALIZE节点，且耗时占比 >70%；SQL Server 中对应Table Spool (Eager) - 同一查询在不同时间生成完全不同的执行计划（比如有时走
Nested Loops，有时变Hash Match），说明优化器已失去稳定性
CTE交叉引用和中间排序会强制全物化
CTE不是语法糖，它是一条明确的执行语义指令。但错误用法会触发非预期物化，把原本可线性展开的逻辑锁死成多步磁盘操作：
- 多个CTE交叉引用（如
A AS (SELECT * FROM B)+B AS (SELECT * FROM A)）→ 优化器无法确定依赖顺序，退化为全物化 - 在中间CTE里加
ORDER BY或LIMIT（SQL Server 用TOP）→ 触发排序或截断，后续无法复用结果集 -
SELECT *写在CTE定义中 → 阻止列剪枝，多余列拖慢物化速度，增加 page fault 概率
MySQL 8.0.23前的CTE默认不物化，反而更危险
MySQL 在 8.0.23 之前没有 MATERIALIZED 提示，CTE 默认行为是“每次引用都重执行”。这意味着：
- 一个被主查询引用3次的CTE，底层子查询真会跑3遍
- 若该CTE含聚合或JOIN，外层10万行 × 子查询平均500行 = 5000万行IO，性能断崖下跌
- 而你看到的
EXPLAIN FORMAT=TREE可能只显示一层Nested loop，根本看不出重复执行
真正卡点：人工验证每层的行数分布与索引命中
别指望工具自动报警。必须手动拆开每一层，用 EXPLAIN ANALYZE 或 SET STATISTICS IO ON 逐层测：
- 查
cleaned_ordersCTE：确认WHERE status = 'paid'是否命中索引，physical reads是几百还是几百万 - 查
daily_channel_summary：看GROUP BY dt, channel是否走索引扫描，还是回表+临时文件 - 查
channel_ranking：验证窗口函数RANK() OVER (PARTITION BY dt ORDER BY gmv DESC)是否触发磁盘排序
复杂点不在“怎么写CTE”，而在“哪一层开始，优化器就不再信任你的条件了”。这个临界点只能靠实测定位，不能靠经验猜。
