max()窗口函数出错主因是order by无法唯一排序，导致窗口边界不确定；须用time与唯一键（如id）组合排序，或通过子查询添加row_number()确保顺序。
为什么 MAX() 窗口函数直接套用会出错
直接写 SELECT MAX(value) OVER (ORDER BY time ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) 看似合理，但实际可能返回全表最大值——尤其当 ORDER BY 列存在重复值且未加 PARTITION BY 或显式唯一排序键时，PostgreSQL 和 SQL Server 会“模糊处理”窗口边界，MySQL 8.0+ 则更严格，但若 time 有重复，仍可能因排序不稳定导致窗口滑动错位。
关键原因：窗口帧（ROWS BETWEEN ...）依赖确定性排序。只要 ORDER BY 子句不能唯一确定每行顺序，数据库就可能任意打乱相等值的先后，让“前两行”变成不可预测的两行。
- 必须确保
ORDER BY表达式组合能唯一标识每一行（例如加主键：ORDER BY time, id） - 避免仅用
ORDER BY time，哪怕业务上认为时间不会重复——数据库不认“业务上” - 如果原始数据无自然唯一键，可临时用
ROW_NUMBER() OVER (ORDER BY time) AS rn辅助排序，再在窗口中按rn定义帧
MySQL 8.0+ 计算 3 行移动最大值的正确写法
MySQL 对窗口函数支持较完整，但默认排序行为容易踩坑。以下是最小可靠写法：
SELECT
time,
value,
MAX(value) OVER (
ORDER BY time, id
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS max_3day
FROM sensor_data;
注意三点：
-
id必须是表中能打破time重复的列（如自增主键），不能是ROW_NUMBER()别名——MySQL 不允许在同一个查询层级中引用别名定义的列用于窗口排序 - 如果表没
id，先用子查询生成序号：SELECT *, ROW_NUMBER() OVER (ORDER BY time) AS rn FROM sensor_data，再在外层用rn排序 -
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW是物理行数，不是时间跨度；想按“最近 3 天”需先过滤或用范围帧（RANGE），但RANGE对MAX()支持有限，且要求排序列为数值型
PostgreSQL 中处理时间重复和 NULL 值的细节
PostgreSQL 默认把 NULL 排在最前（NULLS FIRST），而窗口帧从排序后位置计数。若 time 含 NULL，它们会挤占“前两行”，导致有效数据被排除。
- 显式声明
NULLS LAST：ORDER BY time NULLS LAST, id - 用
CASE WHEN time IS NULL THEN '9999-12-31'::DATE ELSE time END预处理时间列（慎用，避免污染语义） -
MAX()本身会自动忽略NULL值，所以只要帧内至少有一个非空值，结果就正确；但如果帧内全是NULL，结果为NULL，不是 0 或其他默认值 - 若需把全
NULL帧转为 0，套一层COALESCE(MAX(...), 0)
性能陷阱：大数据量下窗口函数变慢的根源
移动最大值看起来只是局部计算，但数据库实际要为每一行重新评估窗口内所有值——没有索引能直接加速 MAX() OVER (... ROWS BETWEEN ...) 的逐行扫描。
- 当表超百万行、窗口宽度大（如
BETWEEN 90 PRECEDING AND CURRENT ROW），执行计划常出现“WindowAgg”节点高成本，CPU 占用飙升 - 替代思路：用递归 CTE 或自连接模拟移动窗口（仅适用于小窗口），或导出到应用层用双端队列（deque）流式计算
- 真正有效的优化是加复合索引：
CREATE INDEX idx_time_id_value ON sensor_data (time, id) INCLUDE (value);—— 覆盖排序和取值，减少回表 - 不要试图用物化视图缓存结果：窗口值随新数据插入实时变化，物化视图刷新成本反而更高
移动窗口最大值的核心约束始终是排序唯一性。无论换什么数据库、加多少索引，只要 ORDER BY 不能线性排列每一行，结果就不可信。这点比函数语法重要得多。
