视图中必须显式使用ROWS BETWEEN定义窗口范围，仅ORDER BY会触发RANGE默认行为导致重复时间戳数据错误聚合；PARTITION BY不可省略以确保分组独立计算；需添加确定性次排序键避免结果不稳定；窗口函数不响应外层WHERE过滤。
视图里能直接写移动平均，但必须用 ROWS BETWEEN 显式定义窗口范围，否则结果不可靠甚至跨组错乱。
为什么视图中只写 ORDER BY 会出错
在视图定义里只写 AVG(col) OVER (ORDER BY ts)，数据库默认按 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 执行——它把所有 ts 相同的行视为“同一位置”，一起参与平均。如果时间戳有重复（比如秒级精度下多笔订单同秒入库），你本想算“最近 5 条记录”的均值，实际却算出了“最近 5 秒内全部记录”的均值。
- 这不是 bug，是 SQL 标准允许的未定义行为
- 同一查询多次运行，若
ts有重复且无第二排序键，结果可能不一致 - 视图一旦创建，这种隐式 RANGE 行为会被固化，后续排查极难察觉
PARTITION BY 必须显式声明，不能省略
如果你的视图要按用户、产品或地区分组计算各自独立的移动平均，PARTITION BY 是强制项。漏掉它，窗口函数会无视分组逻辑，把全表数据拉通计算。
- 例如：按
user_id分组算 7 日移动平均，必须写PARTITION BY user_id ORDER BY event_date - 不加
PARTITION BY，A 用户第 1 天的值可能和 B 用户最后 6 天一起被纳入窗口 - 视图不报错，但业务指标完全失真，且难以通过肉眼校验发现
如何处理开头几行计算不全的问题
用 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 算 3 日均值时，第 1 行只有自身，第 2 行只有前 2 行，不会自动补足 3 行才开始输出。这是正常行为，但容易被误认为“计算缺失”。
- 若需强制从第 3 行起才有值，可用
CASE WHEN ROW_NUMBER() OVER (...) < 3 THEN NULL ELSE ... END过滤 - 更常见做法是保留前 N−1 行的短窗口结果（如第 1 行就是当日值本身），这对趋势观察反而更真实
- 注意：NULL 值默认被
AVG()忽略；若字段本身含 NULL 且你想当 0 参与计算，得先COALESCE(col, 0)
视图定义中的排序列必须具备确定性
仅靠 event_date 排序不够稳——同一天可能有多个事件，数据库无法保证物理顺序。一旦执行计划变化，窗口内“前几行”就可能变。
- 务必补充唯一性第二排序键，例如
ORDER BY event_date, id或ORDER BY event_date, created_at - 避免用
ORDER BY event_date, RAND()这类非确定性表达式，视图将不可重现 - 如果原始表没有合适辅助字段，可在视图里用
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)生成稳定序号再参与排序
最易被忽略的一点：视图里的窗口函数不会自动适配下游查询的 WHERE 条件顺序。如果你在视图外再加过滤（如 WHERE event_date > '2026-01-01'），窗口仍基于视图定义时的完整数据集计算——除非你在视图里就把过滤逻辑收进去，或改用 CTE + 外层包装。
