嵌套视图超过2层就该警惕——不是“可能慢”，而是执行计划大概率失控，因优化器放弃代价估算、谓词下推失效、Materialize节点泛滥、同一查询两次计划完全不同；MySQL 5.7不支持视图合并，PostgreSQL中SELECT *或ORDER BY会强制物化，SQL Server依赖链不可信。
嵌套视图超过2层就该警惕——不是“可能慢”，而是执行计划大概率失控，尤其在MySQL 5.7、SQL Server或PostgreSQL中，谓词下推失效、Materialize节点泛滥、同一查询两次计划完全不同都是明确信号。
为什么嵌套视图会突然变慢？
数据库不会缓存普通视图的中间结果，每次查询都从头展开整个嵌套链。一旦超过2层（比如 v_report → v_summary → v_base），优化器就会放弃精确代价估算：
- 外层
WHERE user_id = 123根本没下推到最底层users表扫描节点，而是先全量算出v_base再过滤 - MySQL 5.7 完全不支持视图合并，哪怕你只查1行，也会扫完整个订单表
- PostgreSQL 中若某层用了
SELECT *或ORDER BY，会强制物化，破坏条件传递路径 - SQL Server 的
sp_depends已弃用，字段被删了你也查不到依赖断裂，上线才报错
哪些写法会让嵌套视图立刻恶化？
问题不在“嵌套”本身，而在嵌套过程中削弱了优化器的推理能力。以下写法几乎必然引发性能断崖：
- 任意一层使用
SELECT *：阻止外层WHERE下推到基表，尤其当后续还有JOIN时 - 连接条件里用函数包装字段，如
ON UPPER(t1.code) = UPPER(t2.code)：索引失效，强制全表比对 - 把大表
JOIN放在视图顶层，却把关键过滤（如WHERE status = 'active'）留在外层查询：等于放任全表扫描 - 嵌套中混用
EXISTS+ 多层子查询：每扫一行外层，内层重跑一次，复杂度变成O(n × m × k)
如何安全地实现“嵌套逻辑”而不真嵌套视图？
用 WITH CTE 替代多层视图，但必须写干净——它不是语法糖，是让优化器看清数据流的结构化表达：
- 每一层 CTE 必须显式列出字段，禁用
SELECT * - 禁止交叉引用，如
a AS (SELECT * FROM b),b AS (SELECT * FROM a)：SQL Server 会全物化 - 中间 CTE 避免
ORDER BY/TOP/LIMIT：它们让结果不可复用，后续JOIN只能重算 - 关键过滤尽早下沉，比如把
WHERE order_date >= '2026-01-01'直接写进最内层 CTE，而不是留到最终SELECT
示例（SQL Server）：
WITH last_order AS ( SELECT user_id, MAX(order_date) AS max_date FROM orders WHERE order_date >= '2026-01-01' GROUP BY user_id ), user_summary AS ( SELECT u.id, u.name, lo.max_date FROM users u INNER JOIN last_order lo ON u.id = lo.user_id ) SELECT * FROM user_summary WHERE max_date > '2026-06-01';
什么时候该放弃“扁平化”，直接物化？
当某段逻辑被多次引用，或含窗口函数、大表聚合、高频 JOIN 时，CTE 每次都会重算——这不是缺陷，是设计使然。此时必须用临时表接管控制权：
- 在存储过程开头用
SELECT INTO #temp_stats显式物化中间结果 - 立刻对常用过滤/连接字段建索引：
CREATE INDEX IX_temp_stats_uid ON #temp_stats(user_id) - 避免把物化当成“兜底方案”：它解决的是重复计算问题，但增加了磁盘 I/O 和维护成本
真正容易被忽略的点是：**嵌套深度只是表象，根本矛盾在于“谁决定何时过滤”。** 视图封装掩盖了这个决策权——你以为加了个 WHERE 就能加速，其实优化器早就放弃了下推。重构时，别问“怎么让视图更快”，先问“哪一层该承担过滤责任”。
