Window Spool 出现在窗口函数无法流式执行时，典型场景包括：PARTITION BY与ORDER BY列无匹配联合索引、窗口帧过大（如UNBOUNDED PRECEDING）、多窗口定义不一致、数据未预排序且内存不足导致spool到tempdb。
Window Spool 运算符不是性能优化器主动选择的“加速器”，而是查询优化器在无法避免时被迫引入的中间结构——它通常意味着窗口函数执行路径中出现了内存或排序瓶颈。
Window Spool 出现在什么查询场景下？
当你使用 OVER 子句且涉及以下任一条件时，Window Spool 很可能被生成：
-
ORDER BY与PARTITION BY字段不匹配（例如PARTITION BY user_id ORDER BY created_at DESC，但索引是(user_id)而无created_at） - 窗口函数需要全量缓存当前分区所有行（如
LAG/LEAD跨多行、ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW） - 查询同时含多个窗口函数，且它们的
PARTITION BY/ORDER BY不一致，无法复用同一排序流 - 底层数据未按窗口逻辑预排序，且 SQL Server 判定内存不足以支撑完整排序流（触发 spool 到 tempdb）
为什么它会让执行计划变重？
Window Spool 是物理运算符，实际行为是：把输入行暂存到 tempdb（Eager Spool 模式）或按需拉取（Lazy Spool），再按窗口逻辑逐行输出。这带来三类开销：
- 额外 I/O：spool 到
tempdb会触发磁盘写入，尤其当分区大、行数多时，actualrows高但actualrewinds也高，说明反复读取 spool 数据 - 内存争用：
Window Spool占用 query memory grant，可能挤占其他并行操作资源，导致 CXPACKET 等等待上升 - 阻塞流水线：
Window Spool必须等整个分区数据就绪才开始输出首行，破坏流式处理能力，延迟首行响应时间
怎么判断是不是它拖慢了查询？
在 XML 执行计划里找 <RelOp LogicalOp="Window Spool" ...>，重点看这几个属性：
-
EstimateRows和ActualRows差距过大 → 表示统计信息不准，优化器误判了分区大小 -
SpoolType="Eager"+TempDbPages> 0 → 明确写了 tempdb，I/O 成为瓶颈点 -
ActualRebinds> 1 且ActualRewinds= 0 → 表明每次外层驱动都重新计算整个分区，没复用结果 - 该节点上游是
Sort或Table Scan，下游是Compute Scalar（窗口计算）→ 典型“先攒再算”路径
能绕过 Window Spool 吗？
不能直接禁用，但可通过改写降低其出现概率：
- 确保
PARTITION BY+ORDER BY字段有覆盖索引，例如CREATE INDEX IX_user_created ON dbo.orders (user_id, created_at) - 避免在同一个 SELECT 中混用不同
OVER子句；拆成 CTE 或子查询，让每个窗口逻辑独立走最优路径 - 用
ROWS BETWEEN CURRENT ROW AND CURRENT ROW替代UNBOUNDED范围（如果业务允许），减少缓存压力 - 对超大分区表，考虑提前物化窗口结果到临时表，用
INDEX+STATISTICS控制执行路径
Window Spool 本身，而是它背后暴露的窗口定义和数据分布之间的错配——你看到的是一个运算符，实际要调优的是分区粒度、索引设计和窗口语义的对齐程度。 
