SQL分组后如何计算移动平均值_利用窗口函数AVG配合ROWS

必须写PARTITION BY，否则窗口函数跨组计算导致结果错误；分组后需在组内按ORDER BY独立排序；ROWS BETWEEN边界自动收缩，重复时间需加唯一键保证稳定性；类型差异需显式转换。SQL里用AVG()加ROWS做分组内移动平均，必须先写PARTITION BY不加PARTITION BY，窗口函数会跨组计算，结果完全不对------比如你按用户分组，却算出了所有用户的混合均值。分组后移动平均的核心逻辑是：先切组，再在组内滑动。漏掉PARTITION BY user_id这类字段，ORDER BY create_time就只是全局排序，不是每组独立排序。常见错误现象：AVG(amount) OVER (ORDER BY create_time ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) 看似合理，但没PARTITION BY，不同用户的记录会混在一起参与滑动计算。必须显式写全分组字段，如PARTITION BY user_id, product_type如果业务上"分组"由多个字段共同决定，少一个就可能合并不该合并的组MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持该语法；SQLite 需 3.25+，旧版不支持ROWSROWS BETWEEN n PRECEDING AND CURRENT ROW 的边界行为要小心滑动窗口默认包含当前行，但起始位置不足时不会报错，而是自动收缩------比如第一行前面没有两行，那窗口就只含它自己。这通常符合预期，但如果你依赖固定长度窗口（如强制3期），就得额外补数据或过滤。使用场景：计算最近3笔订单的平均金额，但首两笔订单永远只有1或2个样本参与计算。ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 实际窗口长度是动态的：1→2→3→3→3...想强制等长？得配合COUNT(*) OVER (...)判断窗口大小，再用CASE过滤或置空注意CURRENT ROW是包含当前行的，别误以为是"之前"的截止点ORDER BY 字段必须有确定性，否则同序记录顺序随机如果ORDER BY create_time存在重复值（比如批量导入导致多条记录时间戳完全一样），数据库可能任意排列这些行，导致同一查询多次执行结果不一致------移动平均值跟着变。 WisPaper 复旦大学研发的AI学术搜索工具，5分钟内筛选1000篇论文