必须配合order by，否则current row无参照基准，结果不可控；其核心用途是“向后探查”，如计算剩余总量、填充空值或识别下一个关键事件。
为什么 CURRENT ROW AND UNBOUNDED FOLLOWING 不能乱用 ORDER BY
这个窗口帧写法本身没问题，但必须搭配 ORDER BY 才有意义。如果只写 PARTITION BY 不排序，Hive/Spark SQL 会默认按任意物理顺序处理，CURRENT ROW 就失去参照基准，结果不可控甚至每次运行都不一样。
常见错误现象：sum(sales_volume) OVER (PARTITION BY sid ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) 返回值全为 NULL 或与预期严重不符。
- 必须显式指定
ORDER BY字段，且该字段应具备业务逻辑上的“方向性”，比如时间戳、序号、版本号 - 排序方向影响语义：用
ORDER BY day_time DESC表示“从当前记录往更早的时间看”，而ASC是“往更晚的时间看” - 若排序字段有重复值，需加二级排序（如
ORDER BY day_time ASC, id ASC）避免非确定性
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 的真实用途场景
它不是用来做“累计求和”的——那是 UNBOUNDED PRECEDING AND CURRENT ROW 的事。它的核心价值是“向后探查”或“向后聚合”，典型用于：
- 填充空值：比如某字段为空时，取后续第一个非空值（
COALESCE(kpsj, FIRST_VALUE(kpsj) IGNORE NULLS OVER (...))配合该帧更稳定） - 计算“剩余总量”：例如每个订单日的销售量，求“从今天起直到本周期结束的总销量”
- 识别下一个关键事件：如
LEAD(event_time, 1) OVER (...)不够用时，用MIN(event_time) OVER (... ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)更健壮
示例（Hive/Spark）：
SELECT id, ssny, kpsj,<br> MAX(kpsj) OVER (PARTITION BY id ORDER BY ssny DESC ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS zwkpsj<br>FROM a;这里按
ssny DESC 排，CURRENT ROW AND UNBOUNDED FOLLOWING 实际覆盖的是“当前年月及更早的所有记录”，从而保证空值能被上一期非空最大值覆盖。
Hive/Spark 与 MySQL/PostgreSQL 在这个语法上的关键差异
MySQL 8.0+ 和 PostgreSQL 支持该语法，但 Hive 和 Spark SQL 对 UNBOUNDED FOLLOWING 的实现更严格，尤其在数据倾斜或分区内无排序时容易报错或静默失败。
- Hive 要求
ORDER BY字段必须是PARTITION BY分组内的确定性排序键，否则可能触发AnalysisException: Window frame RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING requires ORDER BY - Spark SQL 2.x 开始支持，但若底层 shuffle 后分区不完整（如用了
DISTRIBUTE BY而没SORT BY），UNBOUNDED FOLLOWING只能看到本 task 内的数据，导致结果截断 - MySQL 中该帧可用于
RANGE模式，但 Hive/Spark 仅支持ROWS模式；别试图写RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING，会直接报错
容易被忽略的性能陷阱
表面看只是“往后算”，但 UNBOUNDED FOLLOWING 在大数据量下极易引发长尾问题：窗口越大，shuffle 数据越多，尤其当排序字段分布不均（如大量相同 day_time 值）时，单个 reducer 可能扛下整个分区的后续所有行。
- 避免在高基数分组 + 低区分度排序字段（如全为 '2025-01-01'）上使用该帧
- 若业务允许近似，可改用
ROWS BETWEEN CURRENT ROW AND 100 FOLLOWING限制窗口大小 - 在 Hive 中，确认
hive.optimize.windowing已启用（默认 true），否则窗口函数不会做局部优化 - 执行前用
EXPLAIN EXTENDED查看是否生成了WindowOperator+ 大量Shuffle，这是性能红灯
真正难的从来不是写对语法，而是想清楚：你到底需要“从当前行开始往后看到多远”，以及下游系统是否真能承载这个“往后看”的代价。
