为什么SQL视图的嵌套层数建议不超过三层来保证可维护性

三层是优化器放弃谓词下推和稳定执行计划的临界点，超三层后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 后，你敢不敢确认它还在走索引、有没有漏掉条件、会不会某天突然变慢十倍”——三层之后，这些都成了黑盒。