流水账累计求和必须用ORDER BY，否则每行返回全量总和而非逐笔累加；正确写法为SUM(amount) OVER(ORDER BY trans_date, trans_id)，默认窗口为ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，支持正负金额自然累加，但需额外处理期初余额。

流水账累计求和必须用 ORDER BY，否则结果不可控

SQL 中 SUM() OVER() 不加 ORDER BY 默认是“窗口内全量求和”，也就是每行都得到同一总数，完全不符合流水账“逐笔累加”的语义。真正实现余额滚动计算，ORDER BY 是强制前提，且排序字段必须能唯一确定业务时间顺序（比如 trans_date + trans_id）。

常见错误是只按日期排序：ORDER BY trans_date，但同一天多笔交易时，数据库可能任意打乱顺序，导致累计值每次执行都不一致。必须补上可唯一排序的字段：

• 优先用带时间精度的时间戳字段，如 created_at
• 若只有日期和自增ID，用 ORDER BY trans_date, trans_id
• 严禁依赖无序字段（如 ORDER BY amount）

SUM() OVER(ORDER BY ...) 的默认窗口范围是 ROWS UNBOUNDED PRECEDING

很多用户以为要显式写 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 才能累计，其实这是 SUM() OVER(ORDER BY ...) 的隐式行为。只要写了 ORDER BY，窗口自动从第一行扩展到当前行 —— 这正是流水账需要的。

但要注意：一旦你显式写了 ROWS 或 RANGE 子句，就覆盖了默认行为。例如误写成 ROWS BETWEEN CURRENT ROW AND CURRENT ROW，那就变成只算当前行，累计失效。

典型正确写法：

SELECT
  trans_id,
  trans_date,
  amount,
  SUM(amount) OVER (ORDER BY trans_date, trans_id) AS balance
FROM transactions;

处理负数金额（支出）时，SUM() 累加天然支持，但需确认初始余额逻辑

流水账常含收入（正）与支出（负），SUM(amount) 天然适配——正负相加即得净余额。但关键问题在于：第一笔之前的“期初余额”怎么加？

SUM() OVER() 只对当前窗口数据运算，不自动包含期初值。常见做法有两种：

• 在原始数据中插入一行虚拟期初记录：INSERT INTO transactions VALUES (0, '2024-01-01', 10000)，再统一累计
• 用 COALESCE(SUM(amount) OVER (...), 0) + @initial_balance（MySQL）或 LAG() 配合子查询补初始值（更通用）
• 应用层处理：SQL只返回变动额，由程序叠加期初余额

直接在 SUM() 外套 + 10000 最简单，但注意：如果某行 amount 为 NULL，SUM() 会跳过它，而 + 10000 仍生效，逻辑易错。

性能敏感场景下，ORDER BY 字段必须有索引

当表数据量大（如百万级交易记录），ORDER BY trans_date, trans_id 若无对应复合索引，窗口函数会触发全表扫描+外部排序，响应明显变慢。这不是语法问题，而是执行计划瓶颈。

验证方式：执行 EXPLAIN 查看是否用到索引（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）。优化手段明确：

• 建索引：CREATE INDEX idx_trans_order ON transactions(trans_date, trans_id);
• 避免在 ORDER BY 中使用函数，如 ORDER BY DATE(trans_date) 会导致索引失效
• PostgreSQL 用户注意：若用 RANGE 窗口（非默认 ROWS），且排序字段存在重复值，性能可能劣化，坚持用 ROWS + 唯一排序组合最稳

没有索引支撑的累计求和，在千万级表上可能从毫秒级退化到分钟级，这点容易被开发忽略，上线后才暴露。