sum() over 是最稳妥的累计求和方式，但必须明确 order by 和窗口范围，否则结果会错得毫无征兆；需用 partition by 防跨组串扰，补唯一排序键避免同天顺序不定，并通过日期维度表实现连续填充。
直接说结论：SUM() OVER 是最稳妥的累计求和方式，但必须明确 ORDER BY 和窗口范围，否则结果会错得毫无征兆。
为什么 SUM() OVER 比子查询或自连接更可靠？
子查询在大数据量下容易超时，自连接会因 JOIN 条件漏掉边界行（比如首日销售额为 NULL）；而 SUM() OVER 是数据库原生窗口函数，执行计划清晰、结果确定。关键在于它默认按当前行及所有前面的行累加——但这个“前面”完全取决于 ORDER BY 子句，不是物理顺序，也不是主键顺序。
- 没写
ORDER BY→ 窗口无序 → 累计值随机（MySQL 8.0+ 会报错，PostgreSQL 返回不可靠结果） - 用
ORDER BY order_date但存在同天多笔订单 → 同天内顺序未定义 → 累计值可能每次查询都不同 - 正确做法：补上唯一排序键，例如
ORDER BY order_date, order_id
如何避免累计值跨客户/跨产品串扰？
财务报表常需按客户或产品线分组统计累计值。这时候不能只靠 ORDER BY，必须加 PARTITION BY。否则 A 客户最后一天的销售额会累加到 B 客户第一天头上。
- 错误写法：
SUM(amount) OVER (ORDER BY order_date)→ 全表混算 - 正确写法：
SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date, order_id) - 注意：PARTITION BY 的字段必须出现在 SELECT 或 GROUP BY 中，否则某些数据库（如 SQL Server）会报错
- 如果报表要同时看客户级和产品级累计，别嵌套窗口函数，改用两个独立列：
SUM(amount) OVER (PARTITION BY customer_id ORDER BY ...)和SUM(amount) OVER (PARTITION BY product_id ORDER BY ...)
日期断层导致累计值“跳变”怎么处理？
真实销售数据常有空缺日期（比如周末无交易），但财务报表通常要求每日连续展示，缺失日累计值应等于上一个有效日的值（即“向后填充”）。SUM() OVER 本身不支持跳过空行，得配合生成日期维度表或使用 COALESCE + 上一行值模拟。
- 简单场景（已补全日期）：确保源数据含全量日期行，空销额填 0，再跑
SUM(amount) OVER (ORDER BY date) - 硬补日期（推荐）：用递归 CTE 或
generate_series()（PostgreSQL）/numbers表（MySQL）先构造完整日期序列，再 LEFT JOIN 销售表 - 别用
LAG()模拟累计：LAG 只能取上一行，无法解决连续多日为空的问题
真正麻烦的不是语法，而是想清楚“累计”对业务意味着什么：是按订单时间累计，还是按确认收入时间？是否要排除退货？这些逻辑一旦进到窗口函数里，就很难被下游校验。建议把原始累计逻辑封装成视图，并在注释里写明排序依据和空值策略。
