max over 不能直接用 max(price) over (order by bid_time) 因为默认窗口帧是 range between unbounded preceding and unbounded following，导致返回全局最大值而非截至当前行的历史最高价；必须显式指定 rows between unbounded preceding and current row，并建议用 order by bid_time, bid_id 避免时间重复引发的非确定性排序问题。
MAX OVER 为什么不能直接用 MAX(price) OVER (ORDER BY bid_time)
很多人写完就发现结果不对：不是“截至当前行的历史最高价”，而是整个分区的全局最大值。根本原因是没加 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW —— 窗口帧默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，也就是整组都算进去。
必须显式限定窗口范围，否则 MAX() OVER 就退化成普通聚合，失去“动态累积”意义。
- 错误写法：
MAX(price) OVER (ORDER BY bid_time)→ 返回所有记录里的最大 price - 正确写法：
MAX(price) OVER (ORDER BY bid_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) - 如果 bid_time 有重复，建议加
bid_id做二级排序，避免非确定性排序
处理并列时间戳时的稳定性问题
拍卖日志里经常出现同一秒多个出价，ORDER BY bid_time 无法保证顺序，导致相同时间点的 MAX() OVER 结果可能因执行计划不同而波动。
- 加唯一排序键：比如
ORDER BY bid_time, bid_id（假设bid_id是自增主键） - 避免用
RANGE框架（如RANGE BETWEEN ...），它会把同时间戳所有行全拉进窗口，破坏“截至当前出价”的语义 - PostgreSQL 和 SQL Server 支持
ROWS框架；MySQL 8.0+ 也支持，但老版本不认ROWS关键字，会静默回退到RANGE
在 UPDATE 场景中复用窗口函数结果
想把每个出价对应的历史最高价写进表里？别在 UPDATE 里直接嵌套 MAX OVER —— 大多数数据库（如 MySQL、SQL Server）不支持在 UPDATE 的 SET 子句中用窗口函数。
- 必须用派生表或 CTE：先算好
max_so_far，再 JOIN 回原表更新 - 示例（标准写法）：
WITH ranked AS ( SELECT bid_id, price, MAX(price) OVER (ORDER BY bid_time, bid_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS max_so_far FROM bids ) UPDATE bids b JOIN ranked r ON b.bid_id = r.bid_id SET b.highest_so_far = r.max_so_far; - 注意：某些数据库（如 PostgreSQL）允许在
UPDATE ... FROM中直接引用窗口函数，但跨库迁移时建议统一用 CTE 方案
性能敏感时的替代方案
当 bids 表超百万行且频繁查询历史最高价，MAX() OVER 每次都要重算，I/O 和 CPU 开销明显上升。
- 考虑物化：加一列
highest_so_far，在插入新出价时用触发器或应用层计算后写入（适合写少读多） - 索引关键字段：
CREATE INDEX idx_bid_time_id_price ON bids(bid_time, bid_id, price)，让窗口排序和扫描更快 - 避免在
WHERE条件里对窗口函数结果做过滤（如HAVING max_so_far > 100），这会强制全表计算后再过滤，不如先用子查询缩小数据集
