AVG()窗口函数必须配合ORDER BY才能计算移动平均；不写ORDER BY时默认对整个分组做静态平均，而非移动平均，且排序列需唯一或加次级键确保确定性。
AVG() 窗口函数必须配合 ORDER BY 才能计算移动平均
不写 ORDER BY 时，AVG() 窗口函数默认对整个分组做静态平均，不是移动平均。移动平均的本质是“按某列排序后，在滑动窗口内求均值”，所以 ORDER BY 是硬性前提，且排序列通常应是时间戳或序号类字段。
常见错误现象：SELECT AVG(value) OVER (PARTITION BY category ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) 却返回全组均值——根本原因是没加 ORDER BY，导致窗口无法确定“前两行”是谁。
-
ORDER BY必须出现在OVER子句中，不能只靠外层ORDER BY - 若排序列有重复值（如多条记录同一天），需额外加唯一排序键（如主键）避免非确定性结果
- 建议显式使用
ROWS BETWEEN ... AND ...，避免依赖数据库默认框架（有些方言默认是RANGE，行为不同）
ROWS BETWEEN n PRECEDING AND CURRENT ROW 的实际行为
这个范围表示：从当前行往前数 n 行（含），到当前行为止，共 n+1 行参与计算。注意它不会自动补足开头不足 n 行的情况，而是动态截断——首行只有 1 行，第二行有 2 行，直到第 n+1 行才稳定为 n+1 行。
例如计算 3 日移动平均（含当日）：ROWS BETWEEN 2 PRECEDING AND CURRENT ROW：
date value avg_3d 2024-01-01 100 100 ← 只有自己 2024-01-02 80 90 ← (100+80)/2 2024-01-03 120 100 ← (100+80+120)/3 2024-01-04 90 110 ← (80+120+90)/3
- 窗口大小始终是“逻辑行数”，与时间间隔无关；若某天缺数据，不会跳过，也不会插值
-
CURRENT ROW是固定锚点，PRECEDING和FOLLOWING都相对于它计算 - 避免用
UNBOUNDED PRECEDING代替，那会变成累计平均，不是移动平均
分组内移动平均的正确写法：PARTITION BY + ORDER BY + ROWS 缺一不可
要在每个类别内独立计算移动平均（比如每种商品各自的 5 天销量均值），必须同时指定 PARTITION BY 和 ORDER BY，且 ORDER BY 应在 PARTITION BY 之后、ROWS 之前。
典型结构：AVG(value) OVER (PARTITION BY category ORDER BY sale_date ROWS BETWEEN 4 PRECEDING AND CURRENT ROW)
-
PARTITION BY决定分组边界，窗口计算不会跨组 -
ORDER BY在每个组内单独排序，各组排序逻辑互不影响 - 若漏掉
PARTITION BY，所有数据被当做一个大组，结果完全错乱 - 若
ORDER BY列在不同组内语义不一致（如混用不同单位的时间字段），结果不可信
性能和兼容性要注意这些细节
多数主流数据库（PostgreSQL、SQL Server、Oracle、Snowflake、Doris）支持该语法，但 MySQL 8.0+ 才支持 ROWS 框架，MySQL 5.7 及更早版本不支持，会报错 This version of MySQL doesn't yet support 'ROWS'。
- 窗口函数本身比聚合查询更耗内存，尤其当排序列无索引时，可能触发磁盘临时表
- 在 Hive/Spark SQL 中，
ROWS支持良好，但需确认执行引擎（Tez/Spark）配置未禁用窗口函数优化 - 如果需要处理 NULL 值，
AVG()默认忽略 NULL，无需额外WHERE过滤，但要注意这会影响分母计数
最易被忽略的是排序的确定性：哪怕语法全对，只要 ORDER BY 列存在重复且无次级排序键，同一查询多次执行可能返回不同移动平均结果。
