SQL Server 2022中嵌套超3层必致执行计划退化：优化器放弃代价估算，谓词无法下推，导致全表扫描、JOIN错序、rows预估失真；须优先重构含聚合/SELECT*/冗余计算列的视图，并依展开后执行路径建复合索引。
多层嵌套视图在 SQL Server 2022 中不是“自动优化”的，而是极易触发执行计划退化——尤其当嵌套超过 3 层时，优化器常放弃代价估算，导致 JOIN 顺序错乱、索引未下推、甚至全表扫描。
为什么 EXPLAIN 显示 rows 暴涨，而单查子查询却很快？
SQL Server 会将视图展开为一个大查询，但深层嵌套会破坏谓词下推（Predicate Pushdown）能力。你加在最外层的 WHERE user_id = 123，可能根本没传进内层聚合或 JOIN，结果是：先算完百万行的 v_user_orders_summary，再过滤。常见现象包括：
-
EXPLAIN中出现Table Scan或Index Scan（而非Seek），且Estimated Rows远高于实际需要 - 中间结果集字段数爆炸（如某层
SELECT *带出 50 列，但最终只用 3 列） - 执行计划里出现大量
Compute Scalar和Sort，说明优化器在补救别名冲突或 NULL 传播失控
哪些嵌套层级必须拆？
不是所有嵌套都该砍，但以下三类必须优先重构：
- 含聚合 +
GROUP BY的视图被另一视图JOIN多次（如v_order_cnt被v_customer_report和v_region_analytics同时引用）→ 改用带索引的物化视图（CREATE VIEW ... WITH SCHEMABINDING+CREATE UNIQUE CLUSTERED INDEX） - 嵌套中出现
SELECT *或模糊别名（如两表都有id，未显式AS）→ 立即报错Msg 1059或隐式类型转换拖慢性能 - 外层视图仅需某几个字段，但内层视图定义了几十个计算列（如
CASE WHEN+CONVERT+ISNULL堆叠）→ 删除冗余列，或把计算逻辑推迟到调用方
CTE 替代视图的实操边界
CTE 不是“语法糖”，它在 SQL Server 2022 中能否提升性能，取决于是否满足物化前提。盲目替换反而增加解析负担：
- 必须用
WITH的场景：order_summary AS (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id)被后续JOIN和WHERE EXISTS同时引用 ≥2 次 → 可加OPTION (RECOMPILE)触发优化器重估，提高物化概率 - 禁用
WITH的场景：仅单次使用、无参数、逻辑简单（如SELECT id, name FROM customers WHERE status = 'Active'）→ 直接写成INNER JOIN更高效，避免 CTE 引入额外绑定开销 - 关键限制：SQL Server 不支持
MATERIALIZED提示（不像 PostgreSQL/Oracle），所以 CTE 是否物化完全由优化器决定；若观察到执行计划中同一 CTE 出现多次扫描，说明未物化，应改用临时表
真正起效的索引策略
视图性能 = 底层基表索引质量。不要只盯着视图本身加索引，而要按展开后的执行计划反推：
- 对所有
JOIN条件列建复合索引，顺序按等值条件优先（如ON o.customer_id = c.id AND o.status = c.status→ 索引键应为(customer_id, status)） - 外层
WHERE过滤字段若来自底层表，必须出现在索引的INCLUDE列中（如视图查v_orders_summary时加WHERE region = 'CN'，但region在customers表，则索引需INCLUDE (region)） - 避免在视图定义中对字段用函数（如
UPPER(name)），否则索引失效；改用大小写不敏感排序规则（COLLATE SQL_Latin1_General_CP1_CI_AS）
最易被忽略的一点：SQL Server 2022 的统计信息更新机制虽更智能，但视图涉及的基表若长期未 UPDATE STATISTICS，优化器仍可能基于过期分布选错计划——尤其当嵌套中存在 TOP 或 OFFSET-FETCH 时，偏差会被指数放大。
