sql server嵌套视图超3层时优化器必然失控，表现为table spool激增、rebinds远大于1、estimatedrows与actualrows差3个数量级以上；需通过statistics xml查estimaterebinds、验证条件下推、对比行数预估与实际，并用临时表替代cte以实现可控物化。

嵌套视图超过3层，SQL Server优化器会主动放弃代价估算，执行计划不是“可能出错”，而是必然失控——你看到的执行计划XML里反复出现Table Spool (Eager)、Rebinds值飙升、EstimatedRows和ActualRows差3个数量级以上，就是明确信号。

怎么确认是嵌套视图在搞鬼

别只看图形化执行计划是否“看起来正常”。真正要盯的是实际执行时的统计和XML细节：

• 运行SET STATISTICS XML ON后执行查询，在XML中搜索RelOp节点下的EstimateRebinds属性——如果某子查询节点的值远大于1（比如1200），说明它被外层每行都重算了一次
• 检查WHERE条件有没有下推：外层加了WHERE country = 'CN'，但执行计划里regions表的扫描节点没出现这个过滤，就是条件下推彻底失败
• 对比EstimatedRows和ActualRows：比如预估87行，实际扫了92万行，基本可断定优化器已放弃估算，随机选了执行路径

用CTE扁平化时最容易踩的三个坑

CTE不是把视图定义复制粘贴进WITH就完事。SQL Server对CTE的处理很敏感，写错反而比原视图更慢：

• 在CTE里写SELECT *——多余列会阻止外层WHERE下推到基表扫描，尤其后续有JOIN时，I/O和内存开销直接翻倍
• 多个CTE交叉引用，比如a AS (SELECT * FROM b)，b AS (SELECT * FROM a)——优化器无法线性展开，退化为全物化，中间结果全落TempDB
• 在中间CTE里加ORDER BY或TOP——触发排序或截断，后续JOIN无法复用结果，等于白算一遍

什么时候必须上临时表，而不是硬扁平

CTE每次执行都重算，临时表才是可控物化的底线。以下情况不换不行：

• 中间结果集稳定且>1万行，且被外层多次JOIN或WHERE过滤（比如一个查status = 'paid'，另一个查created_at > '2026-04-01'）
• 子查询本身含GROUP BY、窗口函数或大表JOIN——CTE无法让优化器获得准确行数统计，而SELECT INTO #tmp后立刻建索引，能让后续所有操作可预测
• 你发现Table Spool节点耗时占比持续>70%，且physical reads从几千暴增到百万级——这说明TempDB正在成为瓶颈，必须把物化动作收归己控

真正卡点不在语法，而在人工验证每层行数分布

重构嵌套视图最耗时的环节，不是改写SQL，而是逐层验证：regions表加WHERE active = 1后剩多少行？customers关联后膨胀几倍？orders聚合前有多少原始记录？这些数字不落到纸面，任何优化都是赌运气。SQL Server不会告诉你哪一层开始失控，得你亲手用SET STATISTICS IO ON和EXPLAIN等价物去戳。