滑动平均必须用AVG()配合OVER()窗口函数实现，ROWS BETWEEN按物理行数滑动，ORDER BY不可省略，PARTITION BY需对齐业务粒度，UNBOUNDED慎用，主流数据库8.0+支持但旧版需降级处理。
滑动平均必须用 AVG() 配合 OVER()，不能靠子查询模拟
直接写 SELECT AVG(col) FROM t WHERE ... 做逐行范围聚合，性能差且逻辑难维护。窗口函数是唯一合理解法。关键在 ROWS BETWEEN 的偏移定义：它按物理行数滑动，不依赖时间字段值是否连续。比如订单表按 order_id 排序后，ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 就是“当前行加前两行”，共 3 行均值。
常见错误是误用 RANGE——它按值范围切片，遇到重复排序键会意外吞掉多行。例如日期字段有多个同天记录，RANGE BETWEEN INTERVAL '2 days' PRECEDING AND CURRENT ROW 可能拉回 10 行数据，导致均值失真。
ORDER BY 必须存在，且排序字段要能反映业务时序
窗口函数要求显式 ORDER BY，否则报错或结果不可预测。即使你只想按主键递增滑动（如 id），也得写出来：OVER (ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING)。别指望数据库自动按插入顺序排——没有 ORDER BY 就没顺序保证。
真实场景中容易忽略排序字段的业务含义：
- 用
created_at但未处理NULL：需加NULLS LAST或先过滤 - 用
date字段但存在跨月数据：若需“最近 7 天”而非“最近 7 行”，得换RANGE+INTERVAL，但要注意重复日期问题 - 多字段排序时括号缺失：写成
ORDER BY a, b ROWS...是合法的；但若想优先按a、同a时按b稳定排序，必须确保b无重复或加id收尾防歧义
性能敏感点：分区（PARTITION BY）和框架（ROWS）要对齐业务粒度
如果算每个用户的 7 日滑动均值，必须加 PARTITION BY user_id，否则所有用户混在一起算。分区后，窗口只在各用户内部滑动，这是正确性的前提。
框架大小直接影响计算量：
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW是累积平均，每行都要重算前面全部，N 行总代价 O(N²) -
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW固定 7 行，数据库可复用中间结果，基本是 O(N) - 超大表慎用
UNBOUNDED，尤其配合PARTITION BY后单个分区很大时，可能触发内存溢出或降级为磁盘排序
PostgreSQL / MySQL 8.0+ / SQL Server 写法一致，但 SQLite 和旧版 MySQL 不支持
主流新版本都支持标准语法，例如：
SELECT
date,
sales,
AVG(sales) OVER (
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS moving_avg_7d
FROM daily_sales;
SQLite 直到 3.25.0 才支持窗口函数，老版本只能用自连接或应用层计算；MySQL 在 8.0 之前完全不支持，强行升级前得确认客户端驱动兼容性。另外，某些云数仓（如 Redshift）虽标称支持，但 RANGE 子句对 INTERVAL 的解析可能和 PostgreSQL 不一致，上线前务必用真实数据验证边界情况——比如首尾几行是否出现 NULL。
最易被忽略的是：滑动窗口默认不跳过 NULL 值，AVG() 会自动剔除它们，但计数变少可能导致分母过小。如果业务要求“强制 7 天均值”，就得先用 COALESCE(sales, 0) 填零，而不是依赖默认行为。