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