必须用窗口函数实现分组内累加和与移动平均，ORDER BY 不可省且需处理 NULL 和类型转换；移动平均须显式指定 ROWS 框架；大数据量时可拆解为两步优化性能。
用窗口函数实现分组内累加和（running sum）
直接在 GROUP BY 后用 SUM() 只能得到每组总和，不是逐行累加。必须用窗口函数，且 ORDER BY 子句不可省——否则累加顺序无定义，结果不稳定。
常见错误是漏写 ORDER BY 或写错排序字段（比如用时间字段但未处理 NULL），导致同一组内行序随机，累加值每次执行都可能不同。
-
SUM(value) OVER (PARTITION BY category ORDER BY created_at)：按category分组，按时间递增累加 - 若排序字段含
NULL，显式写ORDER BY created_at ASC NULLS LAST（PostgreSQL）或先用COALESCE(created_at, '1970-01-01')（MySQL/SQL Server）兜底 - Oracle 和 PostgreSQL 支持
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但多数场景默认行为即为此，无需显式写出
计算分组内 N 期移动平均（moving average）
移动平均本质是“当前行及前 N−1 行的均值”，必须用 AVG() OVER 配合 ROWS 框架子句。只靠 PARTITION BY + ORDER BY 不够——它默认是累积平均（cumulative avg），不是滑动窗口。
容易混淆的是：ROWS 2 PRECEDING 表示“当前行 + 前两行”，共 3 行；而业务常说的“3日移动平均”正是这个意思。
-
AVG(sales) OVER (PARTITION BY region ORDER BY date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)：每个区域按日期算 3 期移动平均 - SQL Server 2012+、PostgreSQL 11+、Oracle 10g+ 支持该语法；MySQL 8.0+ 也支持，但 MySQL 5.7 不支持窗口函数，得用自连接或变量模拟（不推荐）
- 首两行因数据不足会返回
NULL，如需补零，外层套COALESCE(..., 0)
避免 ORDER BY 引发的隐式类型转换陷阱
当排序字段是字符串型时间（如 '2023-10-01'）时，ORDER BY 按字典序排，'2023-10-10' 会排在 '2023-10-2' 前面——导致累加和与移动平均全乱。
这类问题在线上查数时极难定位，因为单看前几条数据可能碰巧对，但整体趋势异常。
- 强制转日期：
ORDER BY CAST(date_str AS DATE)（标准 SQL）或ORDER BY STR_TO_DATE(date_str, '%Y-%m-%d')（MySQL） - 建表时就用
DATE类型存时间字段，比后期转换更可靠 - 用
EXPLAIN或执行计划确认排序是否走了索引——没索引的ORDER BY在大数据量下会拖慢整个窗口计算
性能敏感场景下的替代方案
窗口函数在千万级表上可能变慢，尤其当 PARTITION BY 组数多、每组行数少但总行数巨大时，数据库仍要全局排序再切分。
这时不如拆成两步：先用 GROUP BY + ROW_NUMBER() 生成有序序列，再用自连接或 LATERAL（PostgreSQL）做局部聚合——虽然 SQL 变长，但可控性强。
- 例如计算每组前 3 行平均值：
ROW_NUMBER() OVER (PARTITION BY id ORDER BY ts) AS rn，然后JOIN自身匹配r1.rn BETWEEN r2.rn AND r2.rn + 2 - SQLite 不支持窗口函数，只能靠 correlated subquery，但数据量超 1 万行就明显卡顿
- ClickHouse 用
runningDifference()或neighbor()更快，但语义不完全等价，需验证边界行为
实际写的时候，先跑 SELECT * FROM ... ORDER BY group_key, sort_col LIMIT 10 看原始顺序是否符合预期，再加窗口函数——顺序错了，后面全错。
