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等价物去戳。
