sql累加求和不能只用sum()，因为sum()是聚合函数，会将多行压缩为单行，无法保留原始行级结构并计算“截至当前行”的累计值；必须使用sum() over()窗口函数，且必须包含order by子句定义累加顺序，否则默认返回分区总和而非逐行累计。

SQL累加求和为什么不能只用SUM()？

因为普通 SUM() 是聚合函数，一用就压缩行数，没法保留原始每行数据的同时显示“到当前行为止的累计值”。必须用窗口函数才能既分组/排序，又逐行计算累积和。

SUM() OVER() 的基本写法和排序关键

累加结果是否正确，完全取决于 ORDER BY 子句——它定义了“累加顺序”。没有 ORDER BY，SUM() OVER() 会默认对整个分区做总和（即每行都显示同一值），不是累加。

• SUM(amount) OVER (ORDER BY create_time)：按时间顺序累加，最常用
• SUM(amount) OVER (PARTITION BY user_id ORDER BY create_time)：先按用户分组，再在组内按时间累加
• 如果 create_time 有重复，建议补上唯一字段（如 id）避免排序不确定：ORDER BY create_time, id

常见错误：NULL值、类型不匹配、ORDER BY漏写

实际执行时容易卡在这几个地方：

• SUM() 遇到 NULL 自动跳过，但如果字段是字符串或布尔型，会报错：ERROR: function sum(text) does not exist，需显式转类型：SUM(amount::numeric)
• 忘记写 ORDER BY，结果每行都是全量总和，看着像“没累加”
• 在 MySQL 8.0 之前不支持窗口函数，会直接报错 ERROR 1064；确认版本用 SELECT VERSION();
• PostgreSQL 中若排序字段含 NULL，默认排在最前，可能让第一行累加值异常，可加 NULLS LAST 控制

和GROUP BY + 子查询比，窗口函数有什么实际优势？

核心是“不丢行、不嵌套、一次扫描”。比如要查订单表每笔订单的累计金额+客户名+下单时间，用子查询得关联或写两层嵌套，而窗口函数一行搞定：

SELECT 
  user_id,
  create_time,
  amount,
  SUM(amount) OVER (PARTITION BY user_id ORDER BY create_time) AS cum_amount
FROM orders;

性能上，窗口函数通常比相关子查询快 2–5 倍，尤其数据量过万后。但注意：如果 PARTITION BY 字段基数极高（比如每行都不同），窗口框架维护开销会上升，这时得权衡是否真需要逐行累加。

真正容易被忽略的是排序稳定性——业务上“同一秒多个订单”，仅靠时间戳无法保证累加顺序与插入顺序一致，补主键或自增 ID 才算兜底。