视图本身不溢出，溢出的是其执行计划中未被正确估算的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 干掉滞留事务。
