窗口函数性能瓶颈源于隐含排序、内存分配及统计偏差，而非over语法本身；需避免高基数列分区、慎用order by累计、限制窗口帧范围、更新统计信息并监控执行计划中的sort、window spool和tempdb分配。
OVER子句本身不慢，慢的是它背后隐含的排序、分组和内存分配逻辑。盲目套用 ROW_NUMBER() 或 SUM() OVER 很可能触发全表排序、TempDB溢出甚至阻塞其他查询。
PARTITION BY 高基数列引发无意义排序
当 PARTITION BY 列几乎唯一（比如 OrderID 主键），SQL Server 仍会强制执行完整排序——即使物理顺序已天然有序。执行计划里出现大流量的 Sort 运算符（Estimated Rows > 百万级），且 Sort Type 是 OrderBy，基本可断定是这个坑。
- 别用
PARTITION BY OrderID去算单行聚合，改用JOIN子查询或直接查源表 - 如果必须用窗口函数，确保
PARTITION BY列有对应索引前导列，例如CREATE INDEX IX_Orders_CustomerDate ON Orders (CustomerID, OrderDate) - 检查
sys.dm_exec_query_stats中该语句的total_logical_reads是否异常高（> 10000）
ORDER BY 在累计计算中导致逐行扫描
SUM(TotalAmount) OVER (PARTITION BY CustomerID ORDER BY OrderDate) 看似合理，但会让 SQL Server 放弃并行，转为串行流式计算，尤其在数据量大、OrderDate 分布稀疏时，性能断崖下跌。
- 确认是否真需要“实时累计”：如果只是按客户汇总总额，用
GROUP BY+JOIN更稳 - 若业务强依赖窗口累计，把
ORDER BY列加入索引，且避免在该列上使用函数（如YEAR(OrderDate)） - 留意执行计划中是否有
Window Spool+Stream Aggregate组合，这是逐行计算的典型特征
未限制窗口帧范围放大内存压力
默认 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 会让 SQL Server 缓存整个分区所有行用于计算。8000万行订单按客户分区，一个热门客户可能占50万行——全加载进内存再逐行累加，极易撑爆 TempDB。
- 能用
ROWS BETWEEN 10 PRECEDING AND CURRENT ROW就别用默认帧，尤其做移动平均类计算 - 监控
sys.dm_db_task_space_usage中该查询的internal_objects_alloc_page_count，持续 > 10000 表示 TempDB 分配严重 - 避免在
SELECT中混用多个不同OVER子句（如同时要ROW_NUMBER和RUNNING TOTAL），它们可能各自触发独立排序
统计信息过旧让优化器误判窗口开销
当表数据量增长但统计信息未更新，优化器可能低估 PARTITION BY 的实际分区数，错误选择哈希匹配或嵌套循环，反而让窗口函数走上低效路径。
- 对高频使用窗口函数的表，定期运行
UPDATE STATISTICS TableName WITH FULLSCAN（尤其分区列变动大时） - 用
DBCC SHOW_STATISTICS('Orders', 'IX_Orders_CustomerDate')查看Steps数量，若远少于实际客户数，说明统计粒度太粗 - 临时启用跟踪标志
TF 2312（兼容性级别 150+）可改善新 Cardinality Estimator 对窗口函数的估算
真正卡住的从来不是 OVER 关键字，而是你没看见的排序、内存分配和统计偏差。执行计划里的 Sort、Window Spool、TempDB 分配量，比任何文档都诚实。
