为什么SQL窗口函数中UNBOUNDED PRECEDING会引起性能问题？

UNBOUNDED PRECEDING 会触发全分区排序与缓存膨胀，迫使数据库放弃流式计算而缓存整个分区数据；其性能劣化源于必须保障每行可访问从分区首行至当前行的全部数据，破坏增量聚合前提。

UNBOUNDED PRECEDING 触发全分区排序和缓存膨胀

它不是“慢一点”，而是让数据库放弃流式计算，转为缓存整个分区数据再逐行处理。只要窗口定义含 UNBOUNDED PRECEDING 且带 ORDER BY，引擎就必须确保每行都能访问从分区首行到当前行的全部数据——这直接破坏增量聚合前提。

常见表现：WindowAgg 节点的 Actual Rows 是输入行数的 N 倍（N = 分区数），Buffers: shared read 猛增，Sort Method: external merge 频繁出现。

• PostgreSQL 在 work_mem 不足时会写临时文件，temp_buffers 占用可达 GB 级
• SQL Server 的 tempdb 日志写入暴涨，常伴随 sort warning 事件
• MySQL 8.0.17 前实际退化为 O(n²) 关联模拟，即使有索引也难规避

ROWS vs RANGE 下 UNBOUNDED PRECEDING 的性能落差极大

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 至少还能按物理行偏移跳指针；而默认的 RANGE 帧在排序键重复时会动态扩展窗口——比如按 sale_date 排序，同一天 1000 笔订单，第 1 行的窗口就已包含全部 1000 行，后续每行都得重扫。

实测中，相同查询在 RANGE 下比 ROWS 慢 5–10 倍，尤其当排序字段基数低（如状态码、枚举）时更明显。

• 业务明确要“同值同处理”（如并列排名）才用 RANGE，否则一律显式写 ROWS
• 时间序列场景慎用 RANGE BETWEEN INTERVAL '7' DAY PRECEDING，重复日期会让窗口失控
• MySQL 对 RANGE 支持有限，PostgreSQL 允许 INTERVAL，SQL Server 不支持日期型 RANGE——跨库迁移时默认帧极易出错

没索引的 ORDER BY 字段会让 UNBOUNDED PRECEDING 彻底失控

引擎无法流式读取，只能先把全部数据拉进内存或磁盘排序。此时 UNBOUNDED PRECEDING 不是语义问题，而是物理执行灾难：排序本身是 O(n log n)，每行累计又是 O(n)，最坏路径接近 O(n²)。

• 对高频 PARTITION BY 字段（如 user_id）建 B-tree 索引，哪怕单字段也能触发 merge-join 路径
• 若 ORDER BY 是表达式（如 date_trunc('month', created_at)），必须建函数索引：CREATE INDEX idx_orders_month ON orders (date_trunc('month', created_at))
• 避免 ORDER BY UPPER(name) 这类无法走普通索引的写法；真要用，得配函数索引且评估代价

UNBOUNDED PRECEDING 并不等于“从表头开始”

这是最容易被忽略的语义陷阱：UNBOUNDED PRECEDING 永远只作用于当前分区，不是全表第一行。如果 PARTITION BY dept_id，那每个部门各自从自己分区的第一行算起——但如果你忘了加 PARTITION BY，又写了 ORDER BY ts，数据库会把整张大表当一个分区，UNBOUNDED PRECEDING 就真成了“从亿级表第一行扫到当前行”。

更隐蔽的是：没写 FRAME 子句时，有 ORDER BY 就默认 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，无 ORDER BY 就默认 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING——后者在 ROW_NUMBER() 场景下也会强制全表排序。

真正关键的不是删掉 UNBOUNDED PRECEDING，而是确认它是否真的需要覆盖整个分区。多数累计需求其实只需要最近 N 行，ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 才是更可控的选择。