嵌套超过3层时，优化器基本放弃代价估算：mysql 8.0+、postgresql和sql server在第4层即停止精确基数估算，转而采用保守执行路径，导致rows预估失真、where无法下推、执行计划随机漂移。
嵌套超过3层时，优化器基本放弃代价估算
MySQL 8.0+、PostgreSQL 和 SQL Server 在视图链达到第4层时，会主动跳过精确基数估算，直接选用保守（且低效）的执行路径。你看到 EXPLAIN 里 rows 从 120 跳到 1200000，不是统计信息不准，是优化器压根没算——它把整条嵌套链当作“黑盒”，默认按全表扫描预估。这种失真会导致 Hash Join 内存溢出、Nested Loop 循环爆炸，甚至触发 Temp table full 错误。
WHERE 条件无法下推到基表是常态，不是例外
哪怕外层只查 SELECT id FROM v_kpi WHERE id = 123，执行计划里仍可能出现 Seq Scan on orders 或 Table Scan on customers。原因很实在：每多一层嵌套，优化器就要多做一次列映射 + 别名绑定 + 语义等价判断；到第3层后，它就懒得追了。典型信号包括：
-
Filter节点始终挂在最外层，基表扫描节点上看不到任何WHERE条件 - MySQL 5.7 中
ALGORITHM=MERGE失效，强制走TEMPTABLE模式 - SQL Server 执行计划 XML 里反复出现
Compute Scalar后接Eager Spool，占比超 60%
错误定位成本远高于重构成本
修改 v_base 的 order_amount 字段为 total_amount，v_kpi 不会立刻报错，但查询时抛 ERROR 1054 (42S22): Unknown column 'order_amount' in 'field list'，堆栈只指向最后一层视图。而真实问题藏在第2层定义里。更麻烦的是：
- MySQL 和 PostgreSQL 的依赖元数据（
pg_depend/INFORMATION_SCHEMA.VIEWS）只记录直接引用，不跟踪跨层字段血缘 - SQL Server 的
sp_depends已弃用，sys.dm_exec_describe_first_result_set穿透嵌套后常返回空列定义 - 开发用
CREATE OR REPLACE VIEW更新中间层，上层视图缓存旧结构，重启服务或手动sp_refreshview才生效
CTE 替代嵌套时最容易踩的三个坑
别以为把 SELECT * FROM v_a JOIN v_b 改成 WITH a AS (...), b AS (...) 就安全了。PostgreSQL 默认物化 CTE，MySQL 8.0.23+ 前无 MATERIALIZED 提示，写法不对反而更慢：
- 在 CTE 里写
SELECT *→ 阻止外层WHERE下推到基表扫描，IO 和内存开销照旧 - 多个 CTE 交叉引用（如
a AS (SELECT * FROM b),b AS (SELECT * FROM a)）→ 优化器退化为全物化，失去线性优势 - 中间 CTE 加
ORDER BY或LIMIT→ 结果集不可复用，后续JOIN必须重算，性能比原嵌套还差
真正难处理的从来不是语法能不能嵌套，而是当你发现 v_kpi 返回结果错位、同比口径不一致、或某天突然变慢十倍时，得手动翻三层视图定义，逐行比对字段来源、过滤条件、聚合逻辑是否同步——这种维护熵值，会在第3次上线变更后指数级上升。
