做数据库优化的都知道，视图嵌套层数这件事，业内一直有“不超过三层”的经验法则。但很多人以为这只是“代码整洁”层面的建议，比如为了好读、好改。其实不然——三层是多数数据库优化器开始“放弃治疗”的临界点，不是风格建议，而是执行逻辑失控的起点。

你写一句 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 后，你敢不敢确认它还在走索引、有没有漏掉条件、会不会某天突然变慢十倍”。三层之后，这些都成了黑盒。