必须指定order by并显式使用rows帧，否则默认range模式会在时间重复时将同值行“捆在一起”累加，导致跳变；不写order by则退化为分组总和而非逐行累计。

为什么 SUM() OVER() 算出来的累计金额和手动加总对不上？

常见原因是没明确指定窗口帧（frame），导致默认行为是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，而时间字段存在重复值时，RANGE 会把同时间戳的所有行“捆在一起”计算，造成跳变。比如两个订单同秒下单，SUM() OVER(ORDER BY create_time) 会把它们的金额同时加进当前行的累计值里，而非逐行累加。

解决方法是强制用 ROWS 帧，或确保排序键唯一：

• 用 ORDER BY create_time, order_id 消除并列，再配合默认帧（此时实际按 ROWS 行为生效）
• 显式写成 SUM(amount) OVER(ORDER BY create_time, order_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
• 避免只靠 create_time 排序，尤其当业务写入精度只有秒级时

ORDER BY 必须带吗？不带会怎样？

必须带。SQL 标准规定，含 ORDER BY 的窗口函数才能定义“累计”语义；不写 ORDER BY，SUM() OVER() 就变成对整个分区（或全表）求和，不是累计——每行结果都一样，等于该分组总金额。

典型误写：SUM(amount) OVER(PARTITION BY user_id) → 这是用户总消费额，不是累计。

正确写法示例（按时间逐笔累计）：

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

如何验证累计值是否真的一行一算？

最直接的办法是抽样比对：取某用户连续几笔订单，手算前 N 笔之和，再查 SQL 输出的 cum_amount 是否严格等于该和。重点检查边界情况：

• 同一用户首单：cum_amount 应等于该单 amount
• 两单金额相同但时间不同：cum_amount 第二行应 = 第一行 + 第二行 amount，不能相等
• 有退款单（负金额）：cum_amount 必须能下降，不能出现“只增不减”的假象

如果发现跳变或平台期，立刻回头检查 ORDER BY 列是否足够唯一、有没有隐式类型转换（比如 create_time 被当成字符串排序）。

在 MySQL 8.0 和 PostgreSQL 里写法有啥细微差别？

核心语法一致，但 MySQL 8.0 对 ORDER BY 中的表达式限制更松（允许列别名），PostgreSQL 要求必须是原始列或表达式。另外，MySQL 默认帧是 ROWS（从 8.0.22 起），而 PostgreSQL 和旧版 MySQL 默认是 RANGE，这点容易被忽略。

跨数据库安全写法：始终显式声明 ROWS，例如：

SUM(amount) OVER(PARTITION BY user_id ORDER BY create_time, order_id ROWS UNBOUNDED PRECEDING)

别依赖默认行为——它既不直观，也不跨版本/跨引擎稳定。

真正麻烦的不是写法，而是排序依据是否真实反映业务顺序。时间字段一旦不准，累计值就不可信，后续所有分析都会漂移。