需显式指定ORDER BY和ROWS框架才能实现“截至当前行”的历史最大值，否则默认RANGE模式在重复排序键下会导致结果跳变。
MAX OVER 需要明确窗口范围，否则默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
直接写 MAX(column) OVER() 会返回整列最大值，不是“截至当前行”的历史最高。关键在定义窗口帧（frame）：SQL 标准中，OVER() 不带 ROWS 或 RANGE 子句时，**默认行为取决于是否排序**——有 ORDER BY 就是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，没排序就是全分区。所以必须显式加 ORDER BY 才能实现逐行累积效果。
常见错误现象：SELECT id, value, MAX(value) OVER (ORDER BY id) AS history_max FROM t 看似可行，但如果 id 有重复，RANGE 模式会把同 id 的所有行视为同一组，导致“当前行”被扩大解释，历史最高值跳变不连续。
- 用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW更稳妥，它按物理行序计算，不受重复排序键影响 - 如果业务上天然无重复排序字段（如自增
id或带毫秒的时间戳），ORDER BY ts+ 默认 frame 也能用 - 注意
RANGE是值域区间，ROWS是行号区间；对“截至当前行”语义，ROWS更符合直觉
PostgreSQL / SQL Server / Oracle 都支持标准语法，但 MySQL 8.0+ 才可用
MySQL 5.7 及更早版本不支持窗口函数，强行使用会报错 ERROR 1064 (42000): You have an error in your SQL syntax。确认版本：运行 SELECT VERSION()，结果需 ≥ 8.0.2（早期 8.0 版本存在部分窗口函数 bug）。
兼容性细节：
- PostgreSQL 和 SQL Server 对
ROWSframe 支持完整，行为一致 - Oracle 中
MAX() OVER在ORDER BY后默认也是RANGE框架，同样建议显式写ROWS - 某些旧版 Presto/Trino 默认用
RANGE，且不支持ROWS关键字，需查文档确认
实际例子：股票每日收盘价，求到当天为止的最高价
SELECT
trade_date,
close_price,
MAX(close_price) OVER (
ORDER BY trade_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS highest_so_far
FROM stock_prices
ORDER BY trade_date;
这个查询输出每行都带截止该交易日的历史最高收盘价。注意三点：
-
ORDER BY trade_date必须和OVER()内的排序一致，外部ORDER BY只影响最终结果顺序，不参与窗口计算 - 如果某天数据缺失，
trade_date出现空缺，窗口仍按现有行计算，“历史最高”不会跳过空档，也不会插值 - 若需排除
NULL值干扰，MAX()本身自动忽略NULL，无需额外处理
性能敏感时，避免在大表上用非索引列排序
窗口函数依赖排序，如果 ORDER BY 字段没有索引，数据库会强制执行一次全表排序，IO 和内存开销陡增。比如 ORDER BY user_name 在千万级用户表上跑 MAX() OVER，可能耗时数秒甚至超时。
- 优先用主键、时间戳、或已建索引的业务字段（如
created_at）作为排序依据 - 如果必须按非索引字段排，考虑先用子查询或 CTE 预排序并限制行数，再套窗口函数
- 在 PostgreSQL 中可通过
EXPLAIN ANALYZE观察是否出现Sort节点及占用内存；SQL Server 看执行计划里的Window Spool成本
ORDER BY，但背后是 RANGE 还是 ROWS 直接决定结果是否符合“截至当前行”的字面意思。 
