MySQL 8.0.2之前不支持ORDER BY与ROWS/RANGE帧组合，导致MAX() OVER无法正确计算历史最高价；需升级版本或改用子查询、变量、应用层处理等兜底方案。
MAX() OVER 为什么不能直接写 ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
MySQL 8.0.2 之前版本会直接报错：Window 'w' with RANGE or ROWS frame requires an ORDER BY clause，即使加了 ORDER BY date 也解析失败——不是语法写错，是旧版引擎根本不支持这种组合。本质是“历史最高价”需要按时间顺序累积计算，而窗口帧语义必须显式声明“从第一行到当前行”，ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 才是正确表达，但得版本够新。
不同数据库怎么写才真正拿到历史最高值
关键在帧定义（frame）和排序字段的配合：
- MySQL 8.0.2+、PostgreSQL、SQL Server：用
MAX(price) OVER (PARTITION BY product_id ORDER BY date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)—— 但注意：如果同一天有多条记录，RANGE会把它们归为同一组，导致所有同日行得到相同最大值 - 日期有重复时，强制按物理顺序累积：改用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW - SQLite 3.25+：不支持
RANGE帧，只能用ROWS，且必须确保ORDER BY包含唯一字段（如ORDER BY date, id），否则排序不稳定
三个容易让结果完全失真的坑
这些错误不会报错，但返回值毫无业务意义：
-
price字段含NULL：MAX 会跳过，但如果第一条记录就是NULL，第二条非空值会被当作“历史最高”，建议先用COALESCE(price, 0)或过滤掉WHERE price IS NOT NULL - 漏写
ORDER BY date：窗口失去时序依据，MAX()变成对每个product_id全量取最大，等价于静态分组聚合，不是“历史”而是“至今总最高” - 分区键写错：比如把
PARTITION BY category_id当成product_id，导致不同商品价格被混在一起比，结果完全不可信 - 日期字段是字符串类型：如
'2023-10-01'和'2023-02-01'按字典序排会错乱，务必确认字段是DATE或DATETIME类型
窗口函数不可用时怎么兜底
MySQL 5.7、旧版 SQLite 等不支持窗口函数的场景下，替代方案效果和稳定性都差一个量级：
- 相关子查询：
(SELECT MAX(t2.price) FROM sales t2 WHERE t2.product_id = t1.product_id AND t2.date —— 数据量稍大就明显变慢，无索引时可能秒变全表扫描 - 用户变量模拟（仅限 MySQL 5.7）：
@max_price := IF(@prev = product_id, GREATEST(@max_price, price), price)—— 必须严格按product_id, date排序，且变量行为在 JOIN、UNION 等复杂查询中极易失效 - 应用层处理更可靠：查出原始数据后，在 Python/Java 里按
product_id分组，用循环维护累积最大值，逻辑清晰、可调试、不依赖数据库版本
真正麻烦的不是语法怎么写，而是当 date 字段存在重复值、NULL 和类型隐式转换时，结果看起来“没错”，却已经偏离业务定义的历史轨迹。
