ROWS BETWEEN 2 PRECEDING AND 1 FOLLOWING 必须配合 ORDER BY 使用，否则窗口无序导致“前后”失效；ORDER BY 列需高唯一性或追加唯一列兜底；加权平均须用 SUM(weight*value)/SUM(weight) 套入窗口函数，并用 NULLIF 防除零；ROWS 按行数计，RANGE 按值范围，时间序列用 RANGE、固定笔数用 ROWS；NULL 和大窗口会显著拖慢性能，应前置过滤。
ROWS BETWEEN 2 PRECEDING AND 1 FOLLOWING 怎么写才生效
必须配合
使用，否则窗口无序，
的“前后”失去意义。SQL 标准要求窗口定义中显式声明排序依据，否则会报错（如 PostgreSQL）或结果不可靠（如 MySQL 8.0+ 警告但执行）。
实操建议：
列应具有高唯一性（如时间戳、自增 ID），避免因排序不稳定导致同一行在不同执行中被划入不同窗口
若业务上需按逻辑顺序（如“用户操作序列”），但排序字段存在重复，应在
中追加唯一列兜底，例如：
MySQL 5.7 不支持窗口函数，该语法直接报错
；确认版本用
加权平均怎么套进滑动窗口里
不能直接用
，因为它是等权平均。加权平均需手动展开为
，且整个表达式必须落在窗口函数内。
常见错误现象：把
写在窗口外，导致聚合跨窗口失效；或误将权重列也参与
排序，引发隐式类型转换。
实操建议：
权重和值都必须是数值型，
会中断计算——提前用
或
过滤
完整写法示例（以销售额加权于门店等级为例）：
防止除零，比
更简洁
ROWS 和 RANGE 的关键区别在哪
按物理行数计数，
按排序值的逻辑范围匹配。对加权滑动平均而言，
是唯一可靠选择。
使用场景差异：
时间序列中“过去 7 天销量加权平均”——必须用
，因为日期可能不连续
但“最近 3 笔订单的金额加权平均”——必须用
，否则同一天多笔订单会被全纳入，破坏“3 笔”语义
PostgreSQL 支持
的
，MySQL 8.0 仅支持数值型
（如
），不支持日期偏移
性能和 NULL 值怎么悄悄拖慢查询
滑动窗口本身不索引友好，
范围越大，每行需扫描的邻近行越多；而加权平均的双重
会让计算量翻倍。更隐蔽的是
值处理逻辑——多数引擎不会跳过
行，而是让整段窗口的聚合结果变
，除非显式过滤。
实操建议：
在
子句提前排除无效数据，比在窗口内用
更高效
若窗口范围固定且较小（如 ±2 行），可考虑用自连接模拟，有时比窗口函数快（尤其在 SQLite 或旧版 MySQL）
PostgreSQL 中
会显示
节点的
，这是排查
影响的直接线索
加权滑动平均真正难的不是语法，而是想清楚“权重依据是否随窗口移动而重算”——比如用累计销量当权重，就不能放在窗口内直接 SUM，得先算出全局累计值再 JOIN。这个细节几乎没人提，但一踩就空跑半小时。
ORDER BYROWSORDER BYORDER BYORDER BY event_time, event_idERROR 1064SELECT VERSION()AVG()SUM(weight * value) / SUM(weight)SUM()OVER()NULLCOALESCE(weight, 0)WHERE weight IS NOT NULLSELECT
store_id,
rating,
sales,
SUM(rating * sales) OVER (
ORDER BY store_id
ROWS BETWEEN 2 PRECEDING AND 1 FOLLOWING
) / NULLIF(SUM(sales) OVER (
ORDER BY store_id
ROWS BETWEEN 2 PRECEDING AND 1 FOLLOWING
), 0) AS weighted_avg_rating
FROM stores;NULLIF(..., 0)CASE WHENROWSRANGEROWSRANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROWROWS BETWEEN 2 PRECEDING AND CURRENT ROWRANGEINTERVALRANGERANGE BETWEEN 10 PRECEDING AND CURRENT ROWROWSSUM()NULLNULLNULLWHERECOALESCEEXPLAIN ANALYZEWindowAggRows Removed by FilterNULL