如何在PostgreSQL中计算移动加权平均值
想在PostgreSQL里算移动加权平均？这事儿没法“一键搞定”。核心逻辑其实不复杂，就是SUM(value*weight) OVER w / SUM(weight) OVER w。但真正做起来，你会发现权重怎么算、窗口怎么对齐、怎么防除零，处处都是细节。下面咱们就拆开揉碎了讲。
PostgreSQL 中没有内置的 mova vg_weighted() 函数，必须手写窗口逻辑
首先得明确一点：PostgreSQL没有现成的移动加权平均函数。自带的a vg()是等权平均，sum() over (…)也没法直接处理权重。所以，你得手动构造那个经典公式。
不过，直接套公式就够了吗？远远不够。一个常见的坑是，很多人直接照搬时间序列里“最近N行”的窗口定义，却忽略了权重本身往往和业务逻辑强相关。比如，按时间衰减的权重，你得先根据时间差算出每行的衰减系数，而不能简单指定一个固定的窗口行数。
这里有几个关键点需要牢记：
- 权重来源：它可能来自另一列（比如
importance），也可能需要动态计算（例如用1.0 / (current_date - event_date + 1)来体现时间衰减）。 - 窗口必须有序：窗口定义里一定要显式加上
ORDER BY。如果只用OVER ()，结果是基于无序集合计算的，每次执行都可能不一样。 - 注意
RANGE的适用性：如果你想按时间范围（比如过去7天）定义窗口，得用RANGE。但要确保排序字段的类型支持范围计算，DATE、TIMESTAMP可以，TEXT可不行。
用 SUM(value * weight) OVER w / SUM(weight) OVER w 是最稳妥的实现方式
目前来看，把加权和与权重和拆成两个独立的窗口计算，再相除，是最稳妥、兼容性最好的方法（PostgreSQL 9.4以上都支持）。别想着去自定义一个聚合函数，那得动用CREATE AGGREGATE，复杂度陡增，得不偿失。
来看一个具体例子：假设我们要计算最近5条记录的加权平均，并且权重按行号倒序分配（最新的权重为5，次新为4，以此类推）。
SELECT
ts,
value,
SUM(value * weight) OVER w / SUM(weight) OVER w AS wma_5
FROM (
SELECT
ts, value,
ROW_NUMBER() OVER (ORDER BY ts DESC) AS rn,
CASE ROW_NUMBER() OVER (ORDER BY ts DESC)
WHEN 1 THEN 5
WHEN 2 THEN 4
WHEN 3 THEN 3
WHEN 4 THEN 2
WHEN 5 THEN 1
ELSE 0
END AS weight
FROM metrics
) t
WINDOW w AS (ORDER BY ts ROWS BETWEEN 4 PRECEDING AND CURRENT ROW);
这段代码里有几个细节值得玩味：
- 权重预计算：权重
weight必须在子查询里提前算好。如果试图在窗口函数里现场计算，很容易导致重复计算甚至语法错误。 - 窗口与排序对齐：外层窗口
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW限定了取最近5行，但权重的分配依赖于按ts DESC排序的行号rn。因此，内外层的排序逻辑必须保持一致。 - 除零保护：这是个必须警惕的陷阱。如果某个窗口内的所有权重碰巧都是0，那么
SUM(weight) OVER w的结果就是0，除法会直接报错。稳妥的做法是加上NULLIF(SUM(weight) OVER w, 0)。
用 ARRAY_AGG + UNNEST 实现动态权重时性能明显下降
有时候，权重无法预先计算，必须根据当前行与窗口内每一行的时间差实时计算。这时，有人会想到一个“灵活”的方法：先用ARRAY_AGG(ROW(ts, value)) OVER w把窗口数据打包成数组，再用UNNEST展开并计算加权和。
这种方法确实能实现任意复杂的权重逻辑，但代价非常高昂：
- 内存压力大：每一行都要构建一个包含整个窗口数据的数组。如果窗口有1000行，内存消耗就会线性增长到几MB，数据量大了根本扛不住。
- 性能杀手：PostgreSQL很难优化这种模式。
UNNEST之后再JOIN或结合LATERAL，很容易引发嵌套循环，导致查询时间从秒级暴增到分钟级。十万行数据可能就让你体验到这个“威力”。 - 使用建议：因此，这种方法只建议在调试逻辑、或者处理极小数据量时使用。生产环境请务必绕道。
时间衰减类加权必须小心处理 NULL 和边界对齐
真实业务中，像“过去7天内，权重按指数衰减（如 e^(-days_ago / 3)）”这样的需求很常见。实现这类逻辑时，有两个细节特别容易出错：
- NULL值陷阱：如果时间戳
ts字段存在NULL值，那么计算CURRENT_DATE - ts时会得到NULL，进而导致整行的权重都变成NULL。关键是，在聚合计算中，NULL权重会被直接忽略，而不是当作0处理，这会导致该行数据完全从加权和中“消失”。 - 稀疏数据导致窗口“缩水”：当你使用
RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW时，如果某些日期根本没有数据记录，那么这些“空”的日子并不会被计入窗口。结果就是，权重和的分母变小了，计算出的平均值会虚高。 - 解决办法：对于NULL，可以用
COALESCE(ts, CURRENT_DATE)来兜底。对于稀疏时间序列，更可靠的做法是先用GENERATE_SERIES生成完整的日期序列，再通过LEFT JOIN关联原始数据，把缺失的日期补上。
说到底，加权平均不是一个黑盒操作。权重如何定义、窗口边界怎么划、空值如何处理，每一个选择都在默默影响最终结果。所以，千万别迷信网上那些“复制粘贴就能跑”的代码。动手之前，先用十来行数据手工验算一下，看看权重和是否符合你的业务预期，这才是避免踩坑的关键。
