加权移动平均需用SUM(price*volume) OVER w / SUM(volume) OVER w实现，核心是窗口内逐行加权求和再相除，必须指定ORDER BY和ROWS BETWEEN，且用NULLIF防除零。
加权移动平均的SQL实现依赖窗口函数和自定义权重逻辑
标准SQL没有内置的WEIGHTED_MOVING_AVERAGE()函数，必须用SUM()配合OVER()窗口子句手动构造。核心是：对每个时间点，取前N行（按日期排序），用交易量作权重，计算价格加权均值。MySQL 8.0+、PostgreSQL、SQL Server 2012+、BigQuery均支持；SQLite和旧版MySQL不支持窗口函数，无法直接实现。
正确写法：用SUM(price * volume) / SUM(volume) + ROWS BETWEEN
错误做法是先算AVG()再加权，或在WHERE里截断行数——这会破坏窗口的动态滑动特性。必须用ROWS BETWEEN N PRECEDING AND CURRENT ROW定义滑动窗口范围，并确保排序字段唯一（如ORDER BY trade_date, trade_id避免并列导致非确定性结果）。
示例（计算5日加权移动均价，以volume为权重）：
SELECT
trade_date,
price,
volume,
ROUND(
SUM(price * volume) OVER (
ORDER BY trade_date, trade_id
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
) / NULLIF(
SUM(volume) OVER (
ORDER BY trade_date, trade_id
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
), 0
), 2
) AS wma_5day
FROM trades;-
4 PRECEDING对应5日（含当前行），不是5 PRECEDING -
NULLIF(..., 0)防止分母为零报错，返回NULL更安全 - 若
trade_date有重复，必须加入第二排序键（如trade_id），否则ROWS行为不可靠
常见错误：权重未归一化、忽略空值传播、时序错乱
典型问题包括：SUM(price) * SUM(volume)（错误地把权重和价格和分别相乘）、用RANGE代替ROWS（导致同日期多笔交易被合并进同一窗口）、未处理price或volume为NULL的数据（使整行从窗口中消失）。这些都会让结果偏离预期。
- 权重必须与价格逐行相乘后求和，不能分离聚合
-
RANGE BETWEEN ...基于值范围，对时间序列极易漏掉数据；务必用ROWS - 提前用
COALESCE(price, 0)和COALESCE(volume, 0)清理空值，否则SUM()跳过该行 - 测试时用
SELECT *, ROW_NUMBER() OVER (ORDER BY trade_date)验证窗口是否覆盖了预期行数
性能与兼容性注意事项
窗口函数在大数据量下可能变慢，尤其当排序字段无索引时。PostgreSQL需确保trade_date上有索引；BigQuery对OVER()优化较好，但ROWS BETWEEN跨度超1000行会触发警告；SQL Server要注意MAXDOP设置影响并行窗口计算效率。
如果目标平台不支持窗口函数（如MySQL 5.7），只能用自连接模拟，但N>3时性能急剧下降，且难以维护。此时建议在应用层计算，或升级数据库版本。
权重设计本身没有SQL约束，但业务上要确认“权重是否应随时间衰减”——如果需要指数衰减（如EMA），SQL就不再适合，得换用Python或专用分析引擎。
