AVG窗口函数加ROWS不能直接用于移动平均，因它自动忽略NULL却不调整分母导致结果偏高，且MySQL 5.7、SQL Server 2012等旧版不支持该组合而报错；稳妥做法是用SUM与COUNT窗口函数手动计算，以精确控制分子分母并兼容各数据库。
SQL移动平均为什么不能直接用AVG窗口函数加ROWS？
因为AVG在ROWS BETWEEN范围内计算时，会自动忽略NULL值但不调整分母——如果某行的值为NULL，它仍按实际非NULL行数做除法，导致结果偏高；更关键的是，很多旧版数据库（如MySQL 5.7、SQL Server 2012）根本不支持AVG与ROWS组合，直接报错Window function 'avg' is not allowed in this context。所以稳妥做法是用SUM除以COUNT，自己控制分子分母逻辑。
用SUM + COUNT窗口函数实现N期移动平均的写法
核心是把移动平均拆成两步：先算窗口内数值和，再算窗口内非NULL个数，最后相除。注意必须用COUNT(column_name)而非COUNT(*)，否则会把NULL也当一行计数。
-
SUM(value) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)计算最近3期（含当前）的和 -
COUNT(value) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)只统计这3行中value非NULL的个数 - 最终表达式：
ROUND(SUM(value) OVER w / NULLIF(COUNT(value) OVER w, 0), 2)，其中w是定义好的窗口名，NULLIF防除零
示例（PostgreSQL/MySQL 8.0+/SQL Server 2016+）：
SELECT
date,
value,
ROUND(
SUM(value) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) * 1.0 /
NULLIF(COUNT(value) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW), 0),
2
) AS ma_3
FROM sales;
ROWS范围边界容易出错的三个细节
ROWS BETWEEN X PRECEDING AND Y FOLLOWING看着直观，但实际执行时边界行为常被误读：
- 起始行从
CURRENT ROW开始算，不是从第一行数据开始——比如ROWS BETWEEN 1 PRECEDING AND CURRENT ROW只取当前行和它前一行，共2行，不是“最近2行” -
PRECEDING和FOLLOWING必须配合ORDER BY字段使用，且该字段需有唯一性或配合RANGE处理并列；否则相同排序值的多行可能被随机包含或排除 - 窗口帧（frame）默认是
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，一旦显式写ROWS，就必须完整写出BETWEEN ... AND ...，漏掉AND CURRENT ROW会语法报错
性能与兼容性差异：不同数据库的实际表现
虽然语法一致，但底层优化差别很大：
- PostgreSQL对
ROWS窗口计算做了帧缓存，100万行内ma_7计算基本无压力；MySQL 8.0在无索引ORDER BY字段时会强制临时表排序，速度骤降 - SQL Server要求
ORDER BY列必须有确定性（比如不能是GETDATE()），否则报错The window aggregate function cannot be used with a non-deterministic ORDER BY - SQLite 3.25+支持，但不支持
NULLIF，得改用CASE WHEN COUNT(...) = 0 THEN NULL ELSE ... END
真正麻烦的是时间序列场景：如果原始数据按天记录，但中间有缺日，ROWS BETWEEN 6 PRECEDING AND CURRENT ROW算的是“最近7条记录”，不是“最近7天”——这点必须靠补全日期维度或改用RANGE配合INTERVAL（仅PostgreSQL支持）来解决。
