SQL如何计算当前行到起始行的最大值_MAX UNBOUNDED用法-SQL-PHP中文网

unbounded preceding 是窗口函数帧起点，需配合 rows between ... and current row 显式声明；默认 range 在重复排序值下会错误聚合，导致累积最大值跳变，务必显式指定 rows 并确保排序键唯一。

sql如何计算当前行到起始行的最大值_max unbounded用法

UNBOUNDED PRECEDING 是窗口函数的起点，不是“当前行到起始行”的额外逻辑

SQL 里没有单独的“当前行到起始行”这种范围语法，MAX() 配合 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 才是标准写法。很多人误以为 MAX() OVER (ORDER BY ... UNBOUNDED) 就能自动生效，其实漏写了 ROWS 子句 —— 这会导致默认使用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，在 ORDER BY 列有重复值时结果可能出错（比如相同时间戳下最大值被提前截断）。

实操建议：

显式写全 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，避免隐式 RANGE 带来的歧义
确保 ORDER BY 列具有足够区分度（必要时加二级排序，如 ORDER BY ts, id）
PostgreSQL / SQL Server / Oracle / BigQuery 都支持该语法；MySQL 8.0+ 同样支持，但 MySQL 5.7 不支持窗口函数

MAX() OVER (...) 的实际行为：累积最大值，不是“全局最大值”

MAX() 窗口函数在 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 下，计算的是从第一行到当前行（含）的所有值中的最大值，即“累积最大值”。它不等价于 MAX(col) OVER ()（后者是整表最大值）。

常见错误现象：

把 MAX(val) OVER (ORDER BY t) 当作“每行都显示历史最高值”，却忘了没写 ROWS，结果因默认 RANGE 在并列 t 值上聚合了未来行（逻辑上属于“同组”），导致值跳变
在未 ORDER BY 的情况下直接用 UNBOUNDED PRECEDING，报错或返回不可预测结果（窗口必须定义排序）

示例（正确写法）：

SELECT
  t,
  val,
  MAX(val) OVER (ORDER BY t ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_max
FROM data;

UNBOUNDED PRECEDING 和 CURRENT ROW 的参数组合影响性能与语义

窗口帧（frame）定义直接影响计算粒度和资源消耗。虽然 UNBOUNDED PRECEDING 看似“从头开始”，但数据库仍需维护一个递增的聚合状态，而非每次全量扫描。

使用场景与注意事项：

数据量大且排序键高度有序（如自增 ID、单调时间戳）时，多数引擎能高效流式计算；若排序键乱序严重，可能触发临时排序 + 多轮遍历，性能下降明显
不能用 UNBOUNDED PRECEDING 替代子查询或自连接来求“前 N 行最大值”——它只支持“到当前行为止”，不支持“往前固定 N 行”
某些旧版 Hive 或 Spark SQL 默认关闭 ROWS 模式，需设置 spark.sql.windowExec.buffer.inMemoryThreshold 等参数防 OOM

容易被忽略的 NULL 处理和类型兼容性

MAX() 窗口函数会自动忽略 NULL 值，但如果所有已扫描行都是 NULL，结果就是 NULL。这不是 bug，是 SQL 标准行为，但常被当作逻辑错误排查半天。

实操建议：

若业务要求用 0 或默认值替代空累积最大值，需套一层 COALESCE(MAX(...), 0)
MAX() 要求参数为可比较类型；对字符串列使用时，注意字符集和排序规则（如 MySQL 中 utf8mb4_0900_as_cs 和 _ci 结果不同）
浮点数列慎用 MAX() 累积，因精度误差叠加可能导致预期外的“不变”或“突变”（尤其在科学计算场景）

真正难的不是写对 UNBOUNDED PRECEDING，而是确认你的排序逻辑是否覆盖了所有业务边界，以及是否意识到 ROWS 和 RANGE 在语义上根本不是一回事。