必须加ORDER BY，否则SUM() OVER()按物理存储顺序累加结果不可靠；它保留原表每行并新增累计列，不同于GROUP BY的行数聚合；需索引优化排序性能，并用COALESCE处理NULL。
累计求和必须加 ORDER BY，否则结果不可靠
PostgreSQL 的 SUM() OVER() 不会自动按时间或 ID 排序，如果窗口定义里没写 ORDER BY，它默认按物理存储顺序累加——这在多数业务场景下等于随机。比如交易表按插入顺序写入，但 VACUUM 或并发写入后物理顺序就不可控。
实操建议：
- 始终在
OVER()中显式声明排序字段，例如OVER (ORDER BY created_at)或OVER (ORDER BY transaction_id) - 若需分客户累计，用
PARTITION BY customer_id ORDER BY created_at，避免跨客户混算 - 注意
created_at有重复值时，应补充二级排序（如ORDER BY created_at, transaction_id）保证确定性
SUM OVER 和普通 GROUP BY 的根本区别在哪
很多人误以为 SUM() OVER() 是“带累计的 GROUP BY”，其实它不聚合行数：原表每行都保留，只是多一列累计值；而 GROUP BY 会把多行压成一行。这是最常混淆的点。
举个例子：一张含 100 笔交易的表，用 SUM(amount) OVER (ORDER BY transaction_id) 仍返回 100 行，每行带截至该笔的累计额；用 GROUP BY date_trunc('day', created_at) 则可能只返回 5 行（按天聚合）。
适用场景：
- 需要保留明细（如展示每笔交易 + 当前累计额）→ 用
SUM() OVER() - 只需要每天/每客户总额 → 用
GROUP BY+ 普通SUM() - 既要分组又要组内累计 →
SUM() OVER (PARTITION BY customer_id ORDER BY created_at)
性能隐患：窗口函数在大数据量下容易慢
SUM() OVER() 是全窗口扫描操作，当交易表超千万行且没合适索引时，排序成本极高。PostgreSQL 不会为窗口函数自动利用索引加速 ORDER BY，除非该字段本身有索引且查询条件能命中。
优化建议：
- 确保
ORDER BY字段（如created_at）建了 B-tree 索引：CREATE INDEX idx_tx_created ON transactions(created_at); - 避免在未过滤的大表上直接跑全量累计，先用
WHERE限定时间范围（如WHERE created_at >= '2024-01-01'） - 若只需最新 N 天累计，考虑物化视图或定时刷新的汇总表，别每次实时算
NULL 值和空集的边界行为要手动处理
SUM() 窗口函数对 NULL 值默认跳过，但若整组都是 NULL（比如某客户所有交易金额为空），结果就是 NULL，而不是 0。这在报表中容易导致前端渲染异常或下游计算中断。
安全写法：
- 用
COALESCE(SUM(amount) OVER (...), 0)把 NULL 转成 0 - 若金额字段本身允许 NULL，建议建表时加
CHECK (amount >= 0)约束，并设默认值 0 - 测试时故意插一条
amount = NULL的记录，确认累计列是否符合预期
窗口函数的逻辑看似简单，但排序依赖、NULL 处理、索引配合这三点，漏掉任何一个都可能让累计值在上线后悄悄出错。
