窗口函数本身不产生spool，而是数据库引擎在无法流式计算时被迫将中间数据暂存至内存或磁盘；根本原因是partition by和order by列缺乏匹配的联合索引，导致全表扫描、排序无法下推或窗口帧过大触发缓冲溢出。
窗口函数本身不产生 Spool，是数据库引擎在无法流式输出结果时，被迫把中间数据暂存到内存或磁盘——这个动作在执行计划里就叫 Spool（SQL Server）或 Materialize / Window Spool（PostgreSQL）。它不是 bug，而是执行模型的必然选择。
为什么 PARTITION BY 列没索引就一定触发 Spool
数据库不会为每个窗口计算动态重排全表数据。当 PARTITION BY user_id 但没有以 user_id 开头的索引时，引擎只能先全表扫描，再用哈希或排序方式分组——这一步必须把所有行拉进内存缓冲，等分组完成才能开始窗口逻辑。哪怕你只取前 10 行，也得先把全部数据分完区。
- PostgreSQL 执行计划里看到
WindowAgg节点下挂Materialize，基本可断定分区列缺失联合索引 - SQL Server 出现
Table Spool (Eager Spool)或Window Spool+tempdb_allocations > 0，说明分区字段未被索引覆盖 - 检查方式：
EXPLAIN (ANALYZE, BUFFERS)看是否出现Seq Scan或高Shared Read值
ORDER BY 字段顺序错乱会放大 Spool 开销
窗口函数依赖物理有序性。如果写的是 PARTITION BY dept ORDER BY hire_date，但索引是 (hire_date, dept) 或只有 (dept) 单列，那么排序无法下推到索引扫描，引擎只能额外加一个 Sort 节点——而这个 Sort 很可能因数据量大溢出到磁盘，进而让后续 Window Spool 缓冲更多行。
- 正确索引必须严格按
PARTITION BY字段在前、ORDER BY字段紧随其后：例如CREATE INDEX idx_dept_hire ON employees(dept, hire_date) - 若
ORDER BY是表达式（如ORDER BY DATE(created_at)），必须建函数索引：CREATE INDEX idx_orders_date ON orders(DATE(created_at)) - 重复使用同一排序逻辑时，SQL Server 2019+ 推荐用
WINDOW w AS (...)显式复用，避免多个OVER子句各自触发独立Sort
RANGE BETWEEN 和重复值会让 Spool 变成“黑洞”
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 看似和 ROWS 一样，实则危险得多。当 ORDER BY 列存在大量重复值（比如 status、DATE(event_time)），数据库必须缓存所有“同值”行才能判断窗口边界——这会导致单个分区的缓冲区远超预期，极易触发内存溢出和磁盘落盘。
- 现象：
EXPLAIN ANALYZE显示Sort Method: external merge Disk: XXXkB（PostgreSQL）或Warning: Operator used tempdb to spill data（SQL Server） - 对策：优先用
ROWS BETWEEN；若必须用RANGE，确保ORDER BY字段高基数，或补唯一字段（如ORDER BY event_time, id） - Spark 场景下更敏感：
spark.sql.windowExec.buffer.in.memory.threshold默认 4096，一旦分区数据行数超限，立刻转UnsafeExternalSorter并可能二次 spill
真正容易被忽略的是：Spool 的规模不只取决于 SQL 写法，更取决于 PARTITION BY 字段的基数分布。按 status（仅 3 个值）分区，等于把全部数据压进 3 个桶；换成 user_id，压力才真正摊开——这种问题在执行计划里从不报错，只能靠 EXPLAIN (VERBOSE) 或 Spark UI 看 partition 数量分布来发现。
