带权重因子的动态加权平均数是权重随时间衰减、用户等级或状态等实时条件动态计算的加权平均，非预存静态列，需在SQL中嵌套表达式生成权重，并用NULLIF防除零，适用于推荐打分、实时风控等场景。
什么是带权重因子的动态加权平均数
它不是简单用 SUM(value * weight) / SUM(weight) 算出来的静态结果，而是指权重本身随行内条件实时计算（比如按时间衰减、按用户等级浮动、按状态开关），且不能预先存成物理列。常见于推荐系统打分、实时风控评分、库存加权均价等场景。
PostgreSQL/MySQL 中用表达式直接算权重
只要数据库支持在 SELECT 或聚合函数中嵌套表达式，就能动态生成权重。关键是把权重逻辑写进 weight 列位置，而不是依赖已有字段。
- 时间衰减权重：用
EXP(-0.1 * EXTRACT(EPOCH FROM (NOW() - created_at)) / 3600)（每小时衰减约10%） - 状态开关权重：用
CASE WHEN status = 'active' THEN 1 ELSE 0.2 END，避免无效数据拉低均值 - 注意：MySQL 8.0+ 才支持窗口函数配合动态权重做滚动加权；5.7 只能靠子查询或变量模拟
- 权重为 0 的行会被
SUM(weight)排除，但若所有权重都为 0，分母会是 0 —— 必须加NULLIF(SUM(weight), 0)防止除零错误
SQL Server 里遇到 Arithmetic overflow error 怎么办
这是最常踩的坑：当 value 是 DECIMAL(18,2)、weight 是 FLOAT，乘积可能超出精度范围，尤其权重含指数运算时。
- 强制转精度：把
value * weight改成CAST(value AS DECIMAL(22,6)) * CAST(weight AS DECIMAL(22,6)) - 别用
FLOAT存权重中间值，改用DECIMAL(18,10)控制舍入行为 - 如果权重来自 UDF 或标量函数，确保函数返回类型明确，否则 SQL Server 可能推断出意外精度
- 测试时用
SELECT TOP 5 value, weight, value * weight AS product看实际中间值，比盲猜更可靠
用窗口函数实现分组内动态加权（如每个商品类目独立计算）
重点不在“加权”，而在“动态”和“分组同时发生”。必须把权重表达式放在窗口帧内，不能先算好再分组。
- 正确写法：
AVG(value * weight) OVER (PARTITION BY category) / AVG(weight) OVER (PARTITION BY category)❌ 错！这算的是两组平均值的比，不是加权平均 - 正确写法：
SUM(value * weight) OVER (PARTITION BY category) / NULLIF(SUM(weight) OVER (PARTITION BY category), 0)✅ - BigQuery 和 Snowflake 支持
AVG() OVER(...)直接加weight参数，但 PostgreSQL/SQL Server 不支持，必须手拆 - 如果分组键多、数据量大，记得给
category和created_at建复合索引，否则动态权重里的函数调用会拖慢整个窗口扫描
动态加权真正的复杂点不在公式本身，而在于权重表达式是否可下推到存储层、是否引入非确定性函数（如 NOW()）、以及不同数据库对 NULL 权重的静默处理差异。上线前务必用真实分布的数据集跑一遍，尤其检查权重趋近于 0 时的边界行为。
