SQL Server窗口函数如何计算移动平均数？

窗口函数实现移动平均，看似基础操作，实际应用中常遇到意料之外的结果或性能瓶颈。语法虽然简洁，但运行起来可能结果不准、速度极慢。下面直接梳理关键要点，避免在相同问题上重复踩坑。

移动平均数该用哪个窗口函数？

直接使用 AVG() 配合 OVER() 即可，无需编写循环或临时表。常见问题不在于函数选错，而在于窗口定义出现偏差——尤其是 ROWS BETWEEN 的范围设定不清晰。

• 必须显式指定窗口框架（ROWS BETWEEN 或 RANGE BETWEEN），因为 SQL Server 默认使用 RANGE UNBOUNDED PRECEDING，结果往往与预期不符。
• 时间序列场景优先选择 ROWS，避免同一时间戳的多条数据被意外聚合。
• ORDER BY 列必须保证确定性顺序，建议包含 id 或 datetime 字段，否则执行计划可能出现异常。

三日移动平均怎么写才不漏数据？

常有人写成 ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING，误以为是“最近三天”，实际是“当前行±1行”，共三行但方向并非按日期滚动。真正的三日移动平均（包含当日）应写成：

AVG(value) OVER (ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)

注意开头两行因缺少足够的前置行，结果返回 NULL。如需补齐，可使用 COALESCE() 或 ISNULL() 处理，但不要依赖 AVG() 的默认行为来“智能凑数”。

• 如果原始数据按 date 排序但中间缺失日期（如周末无记录），ROWS 按物理行数计算，而非日历天数——这是业务逻辑的隐性坑点，务必注意。
• 若需严格按自然日滚动（例如“最近3个完整日历日”），应先创建日期维度表，通过 LEFT JOIN 补全日期，再应用窗口函数。
• 字段名避免使用 value 等关键词，建议使用 sales_amount 等具有明确含义的名称。

性能差到查不动？检查这三个地方

窗口函数本身并不慢，性能瓶颈通常来自底层扫描方式。重点关注执行计划中是否存在大量消耗 CPU 的 Sort 算子，以及是否触发了隐式转换。

• ORDER BY 字段未建索引？添加覆盖索引，如 CREATE INDEX IX_t_date ON table_name(date) INCLUDE (amount)。
• 字段类型混用（例如 date 为 datetime2，但 ORDER BY 中写成 CAST(date AS date)），将直接导致全表扫描。
• 分区表上误用全局 ORDER BY，忘记添加 PARTITION BY，会导致数据跨分区排序，内存急剧膨胀。

为什么结果和Excel手工算的对不上？

最常见原因是 NULL 值处理规则。窗口函数 AVG() 默认跳过 NULL，Excel 的 AVERAGE() 同样会跳过 —— 按理应一致，但问题往往出在数据源本身：SQL 中 NULL 和 0 混用，而 Excel 将空单元格视为 0 计算。

• 用 COUNT(*) 和 COUNT(column) 对比，确认参与平均的行数是否一致。
• 检查原始数据中是否包含字符串型数字（如 '12.5'），隐式转换失败后将变为 NULL。
• 时区或夏令时切换点附近的时间字段，datetime 和 datetime2 的解析差异会导致排序错位。

窗口函数的移动平均，语法上虽然简单，实际工作中最耗费精力的往往是数据质量、时序连续性以及执行计划的隐性约束 —— 不能只看 SQL 语法是否正确，背后的数据逻辑才是关键。