运行总计必须用order by，否则结果不可靠；需显式指定partition by、order by和rows框架，并用coalesce处理null，才能确保跨数据库一致。
运行总计必须用 ORDER BY，否则结果不可靠
窗口函数的 SUM() 要产生有意义的运行总计，ORDER BY 子句不是可选的——它定义了“累计”的顺序。没写 ORDER BY 时，数据库可能按物理存储顺序累加，或返回非确定结果（尤其在 PostgreSQL 或 SQL Server 中）。MySQL 8.0+ 会直接报错。
实操建议：
- 始终在
OVER()里显式指定ORDER BY，例如：SUM(amount) OVER (ORDER BY created_at) - 如果想按多个字段排序（如先按日期、再按 ID），写成：
ORDER BY created_at, id - 避免用无序字段（如
name）做排序依据，重复值会导致相同值的行获得相同累计值，且顺序不确定
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是默认行为，但显式写出更安全
大多数数据库（PostgreSQL、SQL Server、Oracle）中，SUM() OVER (ORDER BY x) 默认等价于 SUM() OVER (ORDER BY x ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)。但 MySQL 8.0 的默认框架是 RANGE，遇到相同排序值时会把它们全算进当前行的累计值里——这往往不是你想要的。
实操建议：
- 明确写出
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，避免跨数据库行为差异 - 不要依赖隐式默认：比如
SUM(sales) OVER (ORDER BY date)在 MySQL 中可能把同一天所有记录一次性累加，而你只想逐行累加 - 若真需要按值范围累计（如“截至当前金额的所有订单”），才用
RANGE，并确认排序字段无重复或已去重
分区后运行总计容易漏掉 PARTITION BY，导致跨组污染
计算每个用户自己的消费累计时，如果只写 ORDER BY created_at 而忘了 PARTITION BY user_id，窗口会把所有用户数据混在一起排序累加，结果完全错误。
实操建议：
- 只要涉及分组累计（如每人、每产品、每月），必须加
PARTITION BY，且放在ORDER BY前面：OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) -
PARTITION BY和ORDER BY的顺序不能颠倒；有些方言（如 BigQuery）允许省略ORDER BY，但此时无法做真正意义上的“运行”总计 - 检查输出：同一分区内第一行的运行总计应等于该行原始值；跨分区边界时，累计值应从零或首行值重新开始
NULL 值会让累计中断，需提前处理
SUM() 窗口函数遇到 NULL 时，会跳过该行参与计算，但累计仍继续——看起来像“断层”。例如三行值为 100, NULL, 50，运行总计是 100, 100, 150，第二行显示的是前一行的累计值，而非“空”，容易误判。
实操建议：
- 用
COALESCE(amount, 0)显式转NULL为 0，确保逻辑一致 - 如果业务上
NULL表示“未发生”，那保留跳过也合理；但必须和团队对齐含义，不能默认忽略 - 测试时故意插入含
NULL的数据，观察结果是否符合预期——这是最容易被跳过的验证点
SUM(COALESCE(value, 0)) OVER (PARTITION BY group_col ORDER BY sort_col ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)。少一个关键词，都可能在某个库或某种数据分布下出错。
