必须显式写order by，否则rows between无效或报错；它提供行序锚点，缺之则数据库无法确定“前几行”，导致报错（如mysql提示缺少order by）或结果未定义。
必须显式写 ORDER BY，否则 ROWS BETWEEN 无效或报错。 这不是可选项，是 SQL 标准强制要求——没有排序依据，数据库根本无法判断“前几行”是谁。
为什么漏掉 ORDER BY 就会出错
常见错误现象：Window definition requires an ORDER BY clause（MySQL）、frame start cannot be greater than frame end（PostgreSQL）等报错，本质都是窗口帧缺少锚点。即使某些引擎（如旧版 PostgreSQL）允许不写 ORDER BY，结果也是未定义的：同一查询多次执行可能返回不同均值。
- 仅靠表物理存储顺序或
GROUP BY不能替代ORDER BY，两者语义完全不同 - 时间字段单独排序不保险：若
event_time有重复（比如批量导入、毫秒级日志聚合），数据库不保证这些行的相对顺序 - 补救办法：加唯一二级排序，例如
ORDER BY event_time, id或ORDER BY event_time, ctid（PostgreSQL）
PRECEDING / FOLLOWING 数字怎么算才不翻车
数字代表“跳过多少行”，不是“总共几行”。这是最常踩的坑——写错一个数，窗口就大一圈或小一截。
-
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW→ 含当前行共 3 行（自身 + 前 2 行）✅ -
ROWS BETWEEN 3 PRECEDING AND CURRENT ROW→ 实际是 4 行，不是“最近 3 天”❌ -
ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING→ 对称 3 行（前 1 + 自身 + 后 1）✅ -
ROWS BETWEEN 5 PRECEDING AND 1 PRECEDING→ 起始 > 结束，直接报错 ❌
边界行为和空值怎么处理才符合业务预期
首尾几行天然行数不足，AVG() 默认只对实际存在的行计算，不会补 NULL 或报错。但业务常误以为“窗口设为 5 就该从第 5 行开始出数”。
- 第 1 行：窗口只有 1 行 → 结果 = 该行值本身
- 第 2 行：最多 2 行参与平均 → 不是
NULL，也不是跳过 - 想让前
n-1行返回NULL？得用CASE WHEN COUNT(*) OVER (...) -
AVG()自动忽略NULL值，但如果整段窗口都为NULL，结果就是NULL；需显式兜底：COALESCE(AVG(col), 0)
真正容易被忽略的是“行”的业务含义是否一致：按 id 排序时中间缺 ID=5，那 ID=6 的“前 2 行”会取 ID=3 和 4，跳过本该代表某天的记录；按时间排序又遇缺失日期，ROWS 不会自动对齐时间维度——它只认位置，不认语义。
