真正触发TempDB溢出的是排序、哈希、去重等隐含操作，需通过sys.dm_db_task_space_usage实时捕获spill会话并定位到具体视图及算子，而非仅检查视图定义。
复杂SQL视图本身不写TempDB，真正触发溢出的是它隐含的排序、哈希、去重操作——监控必须直击这些算子是否spill，而不是只看视图定义。
怎么快速定位是哪个视图在往TempDB灌数据
不能靠猜，得让问题复现时抓实时会话。运行下面查询，同时让业务打开那个“一刷就崩”的报表页面：
SELECT t.session_id, t.request_id, t.task_allocations AS [pages allocated], t.task_deallocations AS [pages freed], q.text AS [sql text] FROM sys.dm_db_task_space_usage t CROSS APPLY sys.dm_exec_sql_text(t.sql_handle) q WHERE t.task_allocations > 10000 ORDER BY t.task_allocations DESC;
重点看 sql text 字段里是否出现 SELECT * FROM dbo.vw_sales_summary 这类模式；再核对 session_id 是否和错误日志里的阻塞链一致（常见伴随 Error 1105 或 Error 3959）。
- 如果
sql text显示的是嵌套多层的 CTE + 视图引用，别急着改视图——先确认最外层是否带ORDER BY或GROUP BY -
task_allocations > 10000是万页阈值，对应约 80MB，已足够触发严重抖动 - 这个 DMV 只捕获当前活跃任务，需在问题发生窗口内执行，否则查不到
视图里有 ORDER BY 就危险？不一定，但多数情况真危险
SQL Server 不会把视图内的 ORDER BY 下推给调用方，它只在视图结果集生成时强制排序——这意味着：哪怕外层加了 TOP 10，只要视图定义里写了 ORDER BY name，整个结果集仍要全排一遍，极易 spill。
- 安全做法：删掉视图里的
ORDER BY，把排序移到最终查询最外层，例如SELECT * FROM dbo.vw_sales_summary ORDER BY sale_date DESC - 如果外层排序字段（如
sale_date）上有索引，优化器可能直接走索引扫描，绕过排序区 - 唯一例外是配合
TOP的ORDER BY，比如SELECT TOP 100 * FROM sales ORDER BY id，此时排序可被截断，内存压力小得多
为什么改完视图还是 spill？检查中间结果有没有“隐形膨胀”
一个常见盲区：视图 A 引用视图 B，B 里有个 DISTINCT，A 再跟大表 JOIN ——这时优化器很可能误估基数，把本该 1 万行的结果膨胀成 50 万行，导致内存 grant 不足，被迫 spill 到 TempDB。
- 用
SET STATISTICS XML ON执行语句，找执行计划里Sort或Hash Match节点的SpillLevel="1"或警告文字"Operator used tempdb to spill data" - 临时表中间结果没索引是最大隐性推手：用
SELECT INTO #tmp落地后，务必补上CREATE CLUSTERED INDEX和关键NONCLUSTERED INDEX，否则后续所有操作都只能全表扫描+再 spill - 如果视图涉及多个大表
JOIN，优先确认连接列是否有索引；没有的话，Hash Match几乎必然 spill，尤其当统计信息过期时
监控 TempDB 空间不能只看总量，得拆到会话和操作粒度
sp_spaceused 返回的是文件级粗略值，对排障几乎无用；真正有效的是两个动态管理视图的组合：
- 查谁在吃内部对象空间：
sys.dm_db_session_space_usage中重点关注internal_objects_alloc_page_count持续上涨的session_id - 查哪个具体操作在分配：
sys.dm_db_task_space_usage关联sys.dm_exec_sql_text，能精确定位到某条SELECT或INSERT语句 - 注意：这两个视图只反映当前会话/任务的累计分配量，不是瞬时占用，所以要在问题发生中执行才有意义
最易被忽略的一点：TempDB spill 往往不是单点问题，而是“排序 → 哈希 → 再排序”的链式溢出。盯住第一个 spill 算子，往往就能切断整条膨胀链。
