移动加权平均价格（mwap）是按时间排序后对最近n行以volume为权重计算的price加权均值，需用rows between显式指定窗口帧、nullif防除零、*1.0保浮点精度，并推荐order by trade_time, trade_id确保稳定排序。
什么是移动加权平均价格（MWAP）？
移动加权平均价格不是 SQL 内置的窗口函数，而是业务定义：对最近 N 行（按时间或序号排序），用每行的 price × volume 加总，再除以这 N 行的 volume 总和。关键在于「加权」来自交易量，不是简单等权平均。
容易误以为 AVG() 窗口函数能直接实现——它只能算等权平均；也有人想用 SUM(price * volume) / SUM(volume) 却忘了限制行数范围，结果算出的是全量加权均值，不是「移动」的。
用 ROWS BETWEEN 实现固定窗口长度的 MWAP
必须显式指定窗口帧（frame），否则默认是 UNBOUNDED PRECEDING TO CURRENT ROW，会累积计算而非滑动。假设你想算最近 5 笔交易（含当前笔）的 MWAP：
SELECT
trade_time,
price,
volume,
SUM(price * volume) OVER (
ORDER BY trade_time
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
) AS weighted_sum,
SUM(volume) OVER (
ORDER BY trade_time
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
) AS vol_sum,
ROUND(
SUM(price * volume) OVER (
ORDER BY trade_time
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
) * 1.0 /
NULLIF(SUM(volume) OVER (
ORDER BY trade_time
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
), 0),
4
) AS mwap_5
FROM trades;
-
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW表示取当前行 + 前 4 行，共 5 行；写成5 PRECEDING就错了，那会变成 6 行 - 务必用
NULLIF(..., 0)防止分母为 0（比如 volume 全为 NULL 或 0 的异常数据） - 乘
* 1.0是为了触发浮点除法，避免整数截断（尤其在 PostgreSQL/SQL Server 中）
ORDER BY 必须明确且稳定
窗口函数依赖 ORDER BY 定义“先后”，如果排序字段有重复值（比如多笔交易发生在同一秒），数据库可能任意打乱行序，导致 MWAP 结果不可复现。
- 推荐组合排序：
ORDER BY trade_time, trade_id（trade_id是唯一递增主键） - 避免只用
ORDER BY price——这不是时间序列逻辑，MWAP 失去意义 - MySQL 8.0+ 和 PostgreSQL 支持
RANGE帧，但用于时间范围（如RANGE BETWEEN INTERVAL '5 MINUTES' PRECEDING AND CURRENT ROW）时，性能通常比ROWS差，且需字段为 datetime 类型、索引支持才高效
性能与边界情况处理
当数据量大（千万级）且窗口跨度大（如 1000 行），SUM() OVER 的计算开销会明显上升，尤其在没有合适索引时。
- 确保
ORDER BY字段上有索引，例如CREATE INDEX idx_trades_time_id ON trades(trade_time, trade_id); - 首 N−1 行的 MWAP 值天然不完整（窗口不足 5 行），此时
SUM(volume)较小，结果波动剧烈——业务上常需标注COUNT(*) OVER (...) 来标记 - 如果要求严格按自然日滚动（非按行数），就得改用
RANGE+ 时间间隔，但要注意：SQLite 不支持RANGE帧，Oracle 对 datetime 的RANGE支持有限制
真正难的不是写出来，是确认「最近 5 笔」是否真等于业务定义的「最近 5 分钟内」，以及 volume 为 NULL 时要不要参与加权——这些都得跟业务方对齐，代码只是执行器。
