MySQL 8.0+、PostgreSQL、SQL Server、Oracle 和 Snowflake 原生支持窗口函数（如 AVG() OVER()）及 INTERVAL 日期语法，而 SQLite 和 MySQL 8.0 以下版本不支持。
确认数据库是否支持窗口函数及日期处理能力
不是所有 SQL 引擎都原生支持 AVG() OVER() 或能正确解析 INTERVAL 类语法。PostgreSQL、SQL Server、Oracle、Snowflake 和较新版本的 MySQL（8.0+）可以；但 SQLite、旧版 MySQL（
执行 SELECT 1 FROM (SELECT AVG(1) OVER(ORDER BY 1 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)) t; 可快速验证窗口函数可用性。若报错 ERROR: window functions not supported 或类似提示，说明当前环境不支持，需改用自连接或子查询模拟。
构造按时间排序的滑动窗口：ROWS vs RANGE 的关键区别
计算“最近三个月”不能只依赖 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW——它数的是行数，不是真实月份。如果某月无销售记录，该月会被跳过，导致窗口实际跨度过短或错位。
必须用 RANGE BETWEEN INTERVAL '2 MONTH' PRECEDING AND CURRENT ROW（PostgreSQL/MySQL 8.0+/Snowflake）或等效表达。注意：
-
RANGE要求ORDER BY列是单调且可比较的时间类型（如DATE或TIMESTAMP），不能是字符串 - MySQL 8.0+ 支持
RANGE BETWEEN INTERVAL ...，但 SQL Server 需用ORDER BY date_col RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW+DATEADD过滤，无法直接写INTERVAL - PostgreSQL 中
INTERVAL '2 MONTH'是日历月（如 3月31日 → 1月31日），非固定 60 天
处理销售数据稀疏或存在重复日期的问题
真实业务中常出现：同一日期多笔订单、某月完全无数据、或日期精度到秒但需按日聚合。直接套用窗口函数会出错或结果失真。
推荐先做预聚合再开窗：
SELECT
sale_date,
daily_sales,
AVG(daily_sales) OVER (
ORDER BY sale_date
RANGE BETWEEN INTERVAL '2 MONTH' PRECEDING AND CURRENT ROW
) AS moving_avg_3m
FROM (
SELECT
DATE(sale_time) AS sale_date,
SUM(amount) AS daily_sales
FROM sales
GROUP BY DATE(sale_time)
) daily;
关键点：
- 用
DATE(sale_time)统一归到日粒度，避免时间戳干扰 - 聚合必须在窗口前完成，否则
AVG() OVER()会对每行原始记录计算，放大误差 - 若某天无销售，该日不会出现在结果中——移动平均天然跳过空缺，这是预期行为；如需补零，得先生成完整日期序列再
LEFT JOIN
性能与索引建议：为什么 ORDER BY 列必须有索引
窗口函数在 ORDER BY date_col 上执行范围扫描时，若 date_col 无索引，PostgreSQL/MySQL 可能触发全表排序，百万级表延迟明显。
检查执行计划是否有 Sort 节点或 Using filesort。优化方式：
- 确保
sale_date字段上有 B-tree 索引：CREATE INDEX idx_sales_date ON sales(date_col); - 若常按时间段过滤再算移动平均，考虑复合索引：
CREATE INDEX idx_sales_date_amount ON sales(date_col, amount); - 分区表（按月）对超大表有效，但窗口跨分区时仍需合并，不能替代索引
窗口函数本身不缓存中间结果，每次查询都重算——如果移动平均被高频调用，且数据变更不频繁，考虑物化为每日快照表更稳。
