如何在SQL Server中利用Window Function计算移动平均数

应使用AVG()配合OVER()窗口函数，关键在于正确设定ROWS BETWEEN框架，时间序列优先用ROWS、ORDER BY需确定性排序，三日移动平均写为ROWS BETWEEN 2 PRECEDING AND CURRENT ROW，注意NULL处理、日期连续性及执行计划优化。

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

直接用 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行”，不是“往前推3行”。真正三日移动平均（含当日）应为：

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

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

窗口函数本身不慢，慢通常来自底层扫描方式。重点看执行计划里是否有 Sort 算子大量占用 CPU，以及是否触发了隐式转换。

• 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 解析差异会导致排序错位

窗口函数的移动平均看似简单，真正麻烦的是数据质量、时序连续性和执行计划的隐性约束——别只盯着语法对不对。