SQL Server 2022嵌套视图超时本质是解析器在3层以上依赖展开时卡死，非性能慢；需切断嵌套而非调参，CTE误用或SELECT *会加剧编译压力，亿级表应改用可索引的临时表。
SQL Server 2022 中嵌套视图编译超时，根本不是“慢”，而是解析器在展开依赖链时直接卡死或报错——尤其当嵌套超过3层，优化器就放弃代价估算，编译阶段可能无限等待、客户端断连，或日志里出现 ERROR 1038 (HY001): Out of sort memory。必须从解析路径上切断嵌套，而不是调参数。
为什么视图嵌套3层以上就不可控
SQL Server 不像 PostgreSQL 那样允许深度嵌套后仍尝试优化；它在编译阶段就对依赖展开做线性递归解析。一旦嵌套超过3层：
- 外层
WHERE几乎无法下推到最底层基表，执行计划里常看到Table Spool (Eager Spool)占比超60% - 估算行数从100跳到500000，说明优化器已放弃基数估算，改用保守上限
- 同一查询不同时间生成完全不同计划（Nested Loops ↔ Hash Match），因为缓存的计划不可复用
-
sp_depends返回结果不准，必须用SELECT OBJECT_NAME(major_id), OBJECT_NAME(minor_id) FROM sys.sql_dependencies手动查真实依赖链
用 CTE 扁平化时哪些写法会让编译更慢
CTE 不是语法糖，它是向优化器传递“可展开”信号的显式结构。但错误用法会触发强制物化或阻断谓词下推，反而加重编译压力：
- 在 CTE 定义里写
SELECT *：多余列阻止外层过滤下推，尤其后续还 JOIN 时，元数据膨胀直接拖慢解析 - 多个 CTE 交叉引用（如
A AS (SELECT * FROM B)和B AS (SELECT * FROM A)）：优化器无法确定展开顺序，退化为全物化 - 中间 CTE 加
ORDER BY或TOP：触发排序或截断，后续无法复用结果集，等于白写 - CTE 内部用
ORDER BY但外层没用OFFSET/FETCH：SQL Server 会保留排序逻辑，增加解析开销
什么时候该弃用 CTE，改用临时表
当嵌套涉及亿级表、实时性要求不高、或需建索引加速 JOIN 时，临时表比 CTE 更可靠——它把编译压力从“每次查询”转移到“一次创建”：
- 临时表可建非聚集索引，比如
CREATE INDEX ix_tmp_orders_cid ON #orders_summary(customer_id, order_date)，让后续 JOIN 稳定走Index Seek - 避免重复解析：CTE 每次执行都重解析，而临时表定义只解析一次，
INSERT INTO #tmp SELECT ...后可多次引用 - 兼容性更强：不依赖兼容级别160，也不受
WINDOW子句限制，老代码迁移成本低 - 注意：临时表需显式
DROP TABLE #xxx或依赖会话结束自动清理，否则可能撑爆tempdb
编译超时最易被忽略的三个点
很多人盯着执行计划看扫描次数，却漏掉真正卡住编译的细节：
- SSMS 查询设计器、ORM 封装（如 Entity Framework 的
AsNoTracking().Select()）、链接服务器调用，都会悄悄增加一层嵌套——实际安全上限常低于25层，而非文档写的32层 - 视图定义里用了
SELECT *，哪怕外层只取两列，SQL Server 仍要解析全部字段元数据，列越多，解析越慢 - 升级到兼容级别160后，
WINDOW子句虽能减少重复解析，但若视图里混用旧式OVER和新式WINDOW，会导致解析器来回切换上下文，反而延长编译时间
