最干净的移动平均计算方式是用avg()配合窗口函数over()，需显式order by并用rows between n preceding and current row控制窗口大小，避免自连接或子查询。
用 AVG() 配合窗口函数直接算，别写自连接
SQL 里算移动平均最干净的方式就是窗口函数，不是用子查询或自连接模拟。主流数据库（PostgreSQL、SQL Server、Oracle、BigQuery、Snowflake、MySQL 8.0+）都支持 AVG() + OVER()，性能好且语义清晰。
常见错误是试图用 GROUP BY 或关联前 N 行来“手动滚动”，结果逻辑错乱、边界处理崩溃、性能陡降。窗口函数天然按排序滚动，不用管索引或行号对齐问题。
-
ORDER BY必须显式指定，否则窗口无意义（比如按时间字段ORDER BY order_date） - 移动窗口大小用
ROWS BETWEEN N PRECEDING AND CURRENT ROW控制，例如 7 日均值写ROWS BETWEEN 6 PRECEDING AND CURRENT ROW - 首 N−1 行会返回
NULL或部分均值（取决于是否加ROWS或RANGE），这是正常行为，不是 bug
MySQL 5.7 或旧版 PostgreSQL 怎么办？
这些版本不支持标准窗口函数，得用变量或相关子查询凑，但必须小心顺序和 NULL 值。
MySQL 5.7 推荐用用户变量模拟累计计数+累加，再除以有效行数。注意：必须用 ORDER BY 子句确保执行顺序，否则变量赋值乱序，结果不可靠。
- 先
SELECT ... FROM t ORDER BY date_col再套变量逻辑，不能省略ORDER BY - 避免在同一个
SELECT中多次引用同一变量（如@sum := @sum + val和@cnt := @cnt + 1混用），MySQL 不保证求值顺序 - PostgreSQL 9.6 及更早可用
generate_series()+LATERAL模拟，但语法冗长、性能差，只建议临时救急
ROWS 和 RANGE 的区别影响结果精度
计算移动平均时，ROWS 按物理行数滚动，RANGE 按排序键值范围滚动——这对时间序列特别关键。
比如你有每日销售数据，但某天缺记录（如周末无数据），用 RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW 会自动跳过空日期，取最近 7 个自然日；而 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 只认表里实际存在的 7 行，可能跨过 10 天甚至漏掉节假日。
- 业务上要“最近 7 天”就用
RANGE（需数据库支持，如 PostgreSQL、SQL Server） - 要“最近 7 条记录”（比如传感器每 5 分钟一条，不管是否连续）就用
ROWS - MySQL 8.0+ 支持
RANGE但仅限数字类型，时间字段得转成UNIX_TIMESTAMP()才能用
性能和 NULL 值怎么处理才不出错？
窗口函数本身很快，但两个地方容易翻车：一是没过滤原始数据里的 NULL，二是没考虑分区导致跨组污染。
-
AVG()窗口默认忽略NULL值，但如果被平均的列本身大量为NULL，结果行数会变少，看起来像“断层”，建议提前用COALESCE(sales, 0)或WHERE sales IS NOT NULL明确意图 - 多设备/多用户数据必须加
PARTITION BY device_id，否则 A 设备的最后几行会和 B 设备的开头几行混进同一个窗口 - 大数据量下，避免在
ORDER BY字段上没索引——特别是用RANGE时，数据库可能无法走索引扫描
真正麻烦的是时间粒度不一致（比如原始数据是分钟级，但你要小时级移动平均），这时得先聚合再开窗，两步不能合并。漏掉这层转换，算出来的“7 小时均值”实际是 7 个零散分钟点的平均，完全失真。
