三层是优化器放弃谓词下推和稳定执行计划的临界点，超三层后where条件无法下推至基表、估算行数严重失真、依赖关系不可信、执行计划随机漂移，cte错误用法反而加剧性能恶化。
三层是多数数据库优化器开始“放弃治疗”的临界点，不是风格建议，而是执行逻辑失控的起点。
视图嵌套超三层后，优化器基本不往下推条件
你写 SELECT * FROM v_orders_summary WHERE country = 'CN'，看起来过滤很明确，但执行计划里 country = 'CN' 可能根本没落到 regions 表的扫描节点上——因为嵌套链太长，优化器直接跳过重写整个子查询树。常见表现包括：
- EXPLAIN 显示
Seq Scan on orders，但实际扫描的是全量订单，而非中国区订单 - 估算行数从 1k 爆涨到 100w，且
Actual Rows和估算严重偏离 - 外层加个
ORDER BY或LIMIT，内层索引就彻底失效
三层以上嵌套让依赖关系不可信
视图 A → B → C → D 这种链式引用，在真实运维中几乎无法验证和追踪：
-
sp_depends（SQL Server）已弃用，对四层链返回空结果 -
pg_depend（PostgreSQL）在多层嵌套下难以准确映射字段来源 - 改
v_c里一个字段别名，可能让v_d的JOIN条件 silently 失效，报错却出现在最外层 - 同一查询在不同时间生成完全不同的执行计划，说明优化器已放弃稳定决策
CTE 替代嵌套视图时，这些写法反而更慢
盲目用 WITH 拆分，并不能自动解决问题；错误用法会让性能雪上加霜：
- 在 CTE 里写
SELECT *—— 多余列会阻止外层WHERE下推到基表 - 多个 CTE 交叉引用（A 依赖 B，B 又依赖 A）—— 打破线性执行顺序，触发全物化
- 中间 CTE 加
ORDER BY或LIMIT—— 强制排序或截断，后续无法复用结果集 - MySQL 8.0.23 之前没
MATERIALIZED提示，CTE 可能被反复执行而非缓存
真正关键的不是“能不能嵌套四层”，而是“改一行 SQL 后，你敢不敢确认它还在走索引、有没有漏掉条件、会不会某天突然变慢十倍”——三层之后，这些都成了黑盒。
