视图本身不溢出，溢出的是其执行计划中未被正确估算的sort和hash match算子；删order by、下推join条件、显式建临时表索引可解决80%问题。

视图本身不溢出，溢出的是它展开后执行计划里那些没被正确估算的 Sort 和 Hash Match 算子——删掉视图里的 ORDER BY、把 JOIN 条件下推、显式建临时表索引，这三步能解决 80% 的实际问题。

怎么确认是视图导致的 TempDB 溢出

别查视图定义，直接跑 SET STATISTICS XML ON，再执行 SELECT * FROM your_view。打开 XML 执行计划，搜索 SpillLevel="1" 或文字警告 "Operator used tempdb to spill data"。重点关注两类节点：RelOp PhysicalOp="Sort"（对应 ORDER BY、TOP、窗口函数）和 RelOp PhysicalOp="Hash Match"（对应 JOIN、GROUP BY、DISTINCT）。如果看到 EstimateRows 是 1000 行但 GrantedMemoryKB 只有 2MB，而实际数据是千万级，基本就是基数误估引发溢出。

为什么视图里加 ORDER BY 会害人

SQL Server 不保证视图内的 ORDER BY 能被外层查询复用或下推；它往往先全量物化结果，再排序，哪怕你只 SELECT TOP 10。更糟的是，嵌套 CTE 或子查询会让优化器彻底“失明”：一个 CTE 声称返回 5 行，外层 JOIN 后实际膨胀到 500 万行，优化器仍按 5 行分配内存，必然 spill。

• 删掉视图定义中所有 ORDER BY，把排序逻辑交给调用方
• 外层查询必须显式写 ORDER BY id DESC LIMIT 10，且 id 字段要有索引
• 避免在视图里用 ROW_NUMBER() OVER (ORDER BY created_at) 这类窗口函数——它强制触发 Sort

临时表替代视图时为何更糟

很多人把视图逻辑改成 SELECT * INTO #tmp FROM ...，以为能缓解压力，结果更严重：SQL Server 默认生成的临时表没有任何索引，后续所有 JOIN、WHERE、GROUP BY 全靠扫描，反复 spill。

• 改用显式建表：CREATE TABLE #orders_agg (user_id INT, order_cnt INT)
• 立刻建聚集索引：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)

容易被忽略的版本存储陷阱

即使 SQL 写得再干净，只要数据库启用了 READ_COMMITTED_SNAPSHOT，而同时存在未提交的长事务（比如一个更新大表的事务卡了 20 分钟），那么视图查询读取的行版本就会一直堆在 TempDB 里，internal_objects_alloc_page_count 持续上涨，sys.dm_db_file_space_usage 中 version_store_reserved_page_count 不降反升——这时候优化语句毫无意义，得先查 sys.dm_tran_active_transactions 干掉滞留事务。