ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 定义从分区首行到当前行的物理行范围，用于累计计算；必须配合 ORDER BY 使用，按排序位置而非值大小纳入行，与 RANGE 的逻辑值范围有本质区别。
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是什么作用
这是窗口函数中 ROWS 框架子句的标准写法，定义当前行及它之前所有行（从分区开头到当前行）为计算范围。它不依赖时间或顺序值，只依赖物理行序（即 ORDER BY 决定的排序位置），常用于累计求和、累计计数、滚动最大值等场景。
必须搭配 ORDER BY 才生效，否则报错或结果不可靠
这个框架依赖明确的行序，所以窗口定义里 ORDER BY 是强制的。没有 ORDER BY 时，数据库可能报错（如 PostgreSQL）、返回非预期结果（如 MySQL 8.0+ 允许但行为未定义），或直接忽略框架（旧版 MySQL 不支持该语法）。
-
SELECT amount, SUM(amount) OVER (ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cumsum FROM sales;✅ 正确 -
SUM(amount) OVER (ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)❌ 缺少ORDER BY，多数引擎拒绝执行
和 RANGE BETWEEN 的关键区别在哪
ROWS 算的是“物理行数”，RANGE 算的是“逻辑值范围”。当 ORDER BY 列存在重复值时，二者行为完全不同：
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：哪怕前几行order_date相同，也只把它们按出现顺序逐行纳入——当前行 + 它前面所有物理行 -
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：会把所有order_date ≤ 当前行 order_date的行全算进来，可能跳过中间某些行、也可能多包一堆重复日期的行
例如按 order_date 排序，若第3、4、5行日期都是 '2024-01-01'，用 ROWS 框架处理第4行时只包含第1~4行；而 RANGE 会把第1~5行全包进去（因为第5行日期也等于当前行）。
性能与分区边界要注意什么
这个写法本身不慢，但实际性能取决于分区大小和排序开销。如果没加 PARTITION BY，整个结果集被当作一个大分区，累计计算会扫描全部数据——大数据量时延迟明显。
- 加
PARTITION BY category可把累计限制在每个分类内，避免跨类干扰，也提升执行效率 - 确保
ORDER BY列有索引（尤其是和PARTITION BY组合时），否则排序成本高 - 注意某些数据库（如 Spark SQL）对超大窗口可能做 spill-to-disk，而
UNBOUNDED PRECEDING容易触发该行为
真正容易被忽略的是：它只保证“从分区起点到当前行”，但如果你误以为它能自动处理“按业务日期连续补零”或“跳过 NULL 行”，那就错了——它不感知业务语义，只认排序后的位置。
