根本原因是窗口函数需临时排序或分组，内存不足导致TempDB溢出；具体表现为执行计划中Sort或Window Spool运算符处理大量行并频繁读写TempDB。
根本原因：窗口函数执行时需要临时排序或分组，而内存不足以容纳全部中间结果
当你在 SQL Server 中看到执行计划里出现 Sort 或 Window Spool 运算符，并且其 Estimated Number of Rows 很大（比如上千万行），同时伴随大量 TempDB 读写，基本可以断定是 OVER 子句触发了溢出。
为什么 PARTITION BY + ORDER BY 会强制排序？
SQL Server 必须按 PARTITION BY 分区、再按 ORDER BY 排序，才能正确计算 ROW_NUMBER()、SUM() OVER(... ORDER BY ...) 等值。这个过程不是流式处理，而是先缓存整个分区的数据，再逐行输出——如果单个分区太大，就会撑爆内存授予（memory grant），被迫把中间数据写入 TempDB。
- 没索引的
PARTITION BY CustomerID ORDER BY OrderDate→ 引擎必须显式Sort，8000万行就极大概率溢出 - 即使加了
WHERE过滤，只要分区键和排序列无对应索引，仍可能全表扫描后排序 -
PARTITION BY列重复值越多，单个分区越大，风险越高
哪些 OVER 用法最容易触发 TempDB 溢出？
不是所有 OVER 都危险，但以下组合在大数据量下非常敏感：
-
SUM() OVER (PARTITION BY A ORDER BY B)—— 累计求和必须维护状态，无法并行流式计算 -
ROW_NUMBER() OVER (PARTITION BY X ORDER BY Y, Z)—— 多列ORDER BY显著增加排序复杂度 -
LAG()/LEAD() OVER (ORDER BY ...)无PARTITION BY却跨全表排序 → 整个结果集都要进内存 - 嵌套窗口：如
MAX() OVER (...) + ROW_NUMBER() OVER (...)→ 多次独立排序
怎么验证是不是 OVER 导致的 TempDB 压力？
别只看监控图表，直接查执行计划和运行时指标：
- 打开实际执行计划，搜索
Sort节点，看Actual Number of Rows是否远超预期；若类型是OrderBy（非RANGE），说明真在排序 - 运行时查
sys.dm_exec_query_stats，过滤出高tempdb_allocations的查询，再关联query_plan找OVER关键字 - 用
SET STATISTICS IO ON，观察是否出现大量tempdb.dbo.Worktable逻辑读 - 检查
sys.dm_db_task_space_usage，确认会话级user_objects_alloc_page_count是否突增
不改逻辑的前提下，如何降低溢出风险？
绕不开排序，就尽量帮 SQL Server 把排序“做在索引里”：
- 为
PARTITION BY和ORDER BY列建复合索引，例如：CREATE NONCLUSTERED INDEX IX_Orders_CustomerID_OrderDate ON Orders (CustomerID, OrderDate) INCLUDE (TotalAmount); - 避免在
OVER中使用表达式排序，如ORDER BY UPPER(FirstName)—— 索引失效 - 用
TOP N或OFFSET-FETCH提前截断结果集，减少参与窗口计算的行数 - 确认是否真需要窗口函数：仅需“每行对应聚合值”，用
JOIN子查询比SUM() OVER (PARTITION BY ...)更轻量
最常被忽略的一点：OVER 的性能不是由语法决定的，而是由它背后隐含的物理操作决定的。你写的是一行 SQL，SQL Server 执行的是一个排序+分组+流式聚合的完整 pipeline。任何一环卡住，都会拖着整个 TempDB 一起喘不过气。
