必须写ORDER BY并加唯一字段兜底，否则ROWS BETWEEN无法确定行序；它按物理行数而非日历天数滑动，缺日期会导致时间跨度失真；边界行自动计算部分窗口均值，非NULL；RANGE BETWEEN兼容性差且语义不稳定，应优先用ROWS。
ORDER BY 必须写，且要带唯一性兜底
不写 ORDER BY，ROWS BETWEEN 就没意义——数据库根本不知道哪是“前两行”。PostgreSQL 直接报错，MySQL 8.0+ 可能静默返回错误顺序结果。更隐蔽的问题是排序字段有重复值，比如多个订单同秒创建，ORDER BY created_at 无法保证每次物理行序一致，导致同一行的移动平均值波动。
解决方法很简单：在 ORDER BY 末尾加一个唯一字段兜底：
-
ORDER BY created_at, id（推荐，id 通常是主键） -
ORDER BY event_time, log_id（日志类场景） - 避免只用
ORDER BY date，尤其当原始数据按天聚合、单日多条记录时
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 不等于“最近3天”
它只认物理行数，不认日历。如果某天没销售记录，窗口不会跳过空缺，而是直接取前两行（可能是前两天 + 大前天），实际跨度变成4天甚至更长。业务上真要“最近7个自然日”的均值，得先补全日期维度：
- BigQuery 用
GENERATE_DATE_ARRAY()左连接 - PostgreSQL / SQL Server 用递归 CTE 构造日期序列
- MySQL 8.0+ 没原生日期生成函数，得靠数字表或临时表模拟
否则，AVG(amount) OVER (ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) 算出来的只是“最近7条记录”的均值，和业务口径大概率对不上。
边界行默认返回部分窗口均值，不是 NULL
第1行窗口只有自己，AVG() 返回该行 amount 值；第2行窗口含自己+前1行，返回这两行的均值。这是标准行为，不是 bug，但容易掩盖数据稀疏问题——比如你看到第1行有值，就以为“3日移动平均已就绪”，其实它根本没滑动。
若需强制只输出满窗结果，加过滤：
-
WHERE ROW_NUMBER() OVER (ORDER BY sale_date) >= 3（3日均值） - 或用
COUNT(*) OVER (ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) = 3显式判断
另外，AVG() 会自动忽略窗口内 NULL 值，但分母按实际非-NULL 行数算——如果整段窗口都是 NULL，结果才是 NULL。
别碰 RANGE BETWEEN，除非你真清楚它怎么算
RANGE BETWEEN INTERVAL '2 days' PRECEDING AND CURRENT ROW 看起来更贴近业务，但支持度极差：MySQL 8.0+ 不支持日期型 RANGE，SQL Server 完全不支持，SQLite 基本不支持。即使 PostgreSQL 支持，也会把同一天所有记录全拉进窗口——比如当天10笔订单，窗口可能含10行而非3行，均值被严重稀释或抬高。
真正稳定可控的方式永远是 ROWS：
-
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW→ 严格3行 -
ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING→ 严格3行，中心对称 - 想“前3日不含当日”，写
ROWS BETWEEN 3 PRECEDING AND 1 PRECEDING
性能上，ROWS 也不依赖索引排序值范围，只要 ORDER BY 字段有索引（如 CREATE INDEX IX_sales_date ON sales(sale_date)），就能避免执行计划里出现大 Sort 算子。
