tempdb溢出是因执行计划中sort或hash match算子内存估算不足导致spill，需通过set statistics xml on查spilllevel="1"或警告文字定位，重点关注sort（order by/top/窗口函数）和hash match（join/group by/distinct）节点，嵌套cte或子查询会加剧基数误估，临时表必须显式建索引，快照隔离下长事务也会滞留版本记录。
查执行计划里哪个算子在 spill
TempDB 溢出不是视图本身的问题，而是它展开后实际执行的物理操作出了问题。直接看视图定义没用，得跑 SET STATISTICS XML ON，然后执行视图查询，从 XML 执行计划里找带 SpillLevel="1" 或警告文字 "Warning: Operator used tempdb to spill data" 的节点。
重点关注两类算子：
-
Sort（对应ORDER BY、TOP、窗口函数） -
Hash Match（对应JOIN、GROUP BY、DISTINCT）
如果看到 RelOp PhysicalOp="Sort" 且 EstimateRows 是百万级但 GrantedMemoryKB 只有几 MB，基本就是内存估算失败导致溢出。
视图里嵌套 CTE 或子查询会放大 spill 风险
SQL Server 对多层嵌套结构的基数估算极不敏感——比如一个 CTE 返回 10 行，外层 JOIN 后膨胀成 2000 万行，优化器仍按 10 行分配内存，结果全 spill 到 TempDB。
改写建议：
- 把
ORDER BY移到最外层，且确保排序字段有索引；子查询里加ORDER BY除非配了TOP，否则纯属浪费 - 避免
SELECT * FROM (SELECT ... FROM t1 WHERE ...) v JOIN t2这种写法；改用显式JOIN+WHERE下推 - 用
OPTION (RECOMPILE)强制重编译，让优化器拿到运行时参数值，有时能避开基数误判
临时表替代视图中间结果时必须建索引
很多人把视图逻辑拆成 SELECT INTO #tmp，以为能缓解压力，结果更糟：默认生成的临时表无任何索引，后续所有 JOIN、WHERE、GROUP BY 全靠扫描，反复 spill。
正确做法是显式建表并提前建索引：
CREATE TABLE #orders_agg (
user_id INT,
order_cnt INT,
total_amt DECIMAL(18,2)
);
CREATE CLUSTERED INDEX IX_#orders_agg_user_id ON #orders_agg (user_id);
尤其注意非聚集索引要覆盖常用过滤/连接字段，比如 CREATE NONCLUSTERED INDEX IX_#orders_agg_status ON #orders_agg (status) INCLUDE (order_cnt)。
快照隔离和长事务会让 TempDB “卡住”释放不了
即使你优化了所有 SQL，如果数据库启用了 READ_COMMITTED_SNAPSHOT，而同时存在长时间未提交的事务（比如更新同一张大表），那么视图查询读取的版本记录就一直堆在 TempDB 里，internal_objects_alloc_page_count 会持续上涨，收缩无效。
确认方式：
- 查
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME() - 查活跃快照事务：
SELECT session_id, elapsed_time_seconds FROM sys.dm_tran_active_snapshot_database_transactions WHERE elapsed_time_seconds > 300
真正难处理的，是那些执行计划看着“干净”，却因统计信息陈旧、内存授予偏差或快照版本滞留，悄悄把 TempDB 填满的视图——它们不报错，只拖慢整个实例。
