PARTITION BY在滚动平均中仅负责按指定列分组，使窗口函数在各组内独立计算；真正的滚动逻辑由ORDER BY（定义排序）和ROWS BETWEEN（定义窗口范围）共同实现。
什么是PARTITION BY在滚动平均中的真实作用
PARTITION BY 本身不提供“滚动”能力，它只是把数据按列分组，让后续的窗口函数（比如 AVG()）在每个组内独立计算。真正的滚动逻辑来自 ORDER BY + ROWS BETWEEN。很多人误以为加了 PARTITION BY 就能自动按时间滑动，结果发现所有值都一样——那是因为没配 ORDER BY，窗口默认是 UNBOUNDED PRECEDING TO CURRENT ROW，但没排序的话“当前行”在物理上是无序的。
-
PARTITION BY决定「在哪一组里算」，比如按product_id分开算每个商品的滚动均值 -
ORDER BY决定「按什么顺序滚」，必须是时间字段或可排序序列（如sale_date、seq_num） -
ROWS BETWEEN才定义窗口大小，例如ROWS BETWEEN 2 PRECEDING AND CURRENT ROW表示含自己往前共3行
写法示例：过去3天销售金额的动态滚动平均
假设表叫 sales，字段有 product_id、sale_date、amount，要为每个商品单独计算「截至当天、包含当天及前两天」的平均销售额：
SELECT
product_id,
sale_date,
amount,
AVG(amount) OVER (
PARTITION BY product_id
ORDER BY sale_date
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS rolling_avg_3d
FROM sales;
注意点：
-
sale_date必须是 DATE 或能正确排序的类型；如果存的是字符串（如'2024-05-01'），得先CAST(sale_date AS DATE)，否则排序可能错乱 - 如果某商品在某天无记录，该天不会出现在结果中——
PARTITION BY不会补空行，也不会跨天插值 -
ROWS是物理行偏移，不是时间跨度；若中间缺某天，窗口仍取最近的2条记录，不是严格“过去72小时”
常见错误：NULL结果、重复计算、性能卡顿
遇到结果全为 NULL，大概率是 ORDER BY 字段含 NULL 值——多数数据库（PostgreSQL、SQL Server）把 NULL 排在最前，导致第一行窗口里只有自己且值为 NULL，AVG(NULL) 返回 NULL。解决方法：
- 在
ORDER BY后加NULLS LAST（PostgreSQL/Oracle 支持） - 或提前过滤：
WHERE sale_date IS NOT NULL
重复计算问题常出现在 JOIN 后没去重就直接开窗——PARTITION BY 会忠实按 JOIN 后的每一行分组，若一对多产生冗余行，滚动平均就重复刷同一组数据。建议：
- 窗口函数套在最内层聚合后（如先
GROUP BY product_id, sale_date汇总日销量） - 或用
DISTINCT ON（PostgreSQL）/ROW_NUMBER()去重
性能方面，PARTITION BY + ORDER BY 要走排序，大数据量时务必确保 (product_id, sale_date) 有联合索引，否则全表排序极易拖慢。
MySQL 8.0+ 和旧版兼容性差异
MySQL 8.0 开始支持完整窗口函数，但 5.7 及更早版本完全不支持 OVER。迁移时要注意：
- MySQL 8.0 中
ROWS BETWEEN的语法和 PostgreSQL 一致，可直接复用 - 但 MySQL 对
NULLS LAST不支持，需改用ORDER BY IFNULL(sale_date, '1970-01-01')这类兜底写法 - 如果必须兼容老版本，只能用自连接或变量模拟滚动窗口，但逻辑复杂、不可靠，且无法高效处理
PARTITION BY多组场景
真正容易被忽略的是：滚动窗口的边界行为。比如第一行，2 PRECEDING 实际只取到自己；而最后一行，即使写了 2 FOLLOWING，也没后续数据可拉。这些边界不会报错，但结果可能不符合业务预期——得结合具体场景判断是否需要补零、截断，或改用 RANGE（仅部分数据库支持基于值的范围）。
