SUM OVER 累计错误主因是排序粒度不足或缺失 PARTITION BY，导致同月多记录重复累加或跨部门混算；须用唯一排序键（如 month, id）、显式 ROWS UNBOUNDED PRECEDING 及按业务维度（部门/财年）合理分区与排序。
为什么 SUM OVER 会把累计值算错？
直接写 SUM(budget) OVER (ORDER BY month) 很容易得到错误结果，尤其当某个月有多个预算记录（比如多条支出或分项预算）时，窗口函数会先按行聚合再累加，导致重复计算。关键不是“能不能用”，而是“怎么定义排序粒度”——必须确保 ORDER BY 的字段组合能唯一标识时间维度的递增顺序，且不引入额外分组歧义。
- 如果原始表里
month是字符串（如'2024-01'），要确认它严格按字典序可排序；否则换成YEAR(month)*100 + MONTH(month)类数值表达式 - 存在同月多条记录时，不能只靠
month排序，得补上稳定排序键，比如ORDER BY month, id（id需为自增主键或业务上无重复的序号） - 别在窗口函数里漏掉
PARTITION BY：跨项目、跨部门预算必须隔离计算，否则 A 部门的 1 月数据会被 B 部门的 2 月数据拉高累计值
SUM OVER 和 GROUP BY 混用时的陷阱
常见做法是先 GROUP BY month 汇总每月实际消耗，再套一层窗口函数算累计。但要注意：如果原始明细表含未归类预算（如 category IS NULL），GROUP BY 会把它们全挤进同一组，导致首月累计虚高。更稳妥的是在聚合前过滤或打标。
- 先聚合再开窗的典型写法：
SELECT month, monthly_sum, SUM(monthly_sum) OVER (PARTITION BY dept ORDER BY month) AS cum_sum FROM (SELECT dept, month, SUM(amount) AS monthly_sum FROM budget_log GROUP BY dept, month) t
- 如果需要保留明细行（比如展示每笔支出+当月累计+历史累计），就不能提前
GROUP BY，而要用SUM(amount) OVER (PARTITION BY dept, month)先算月度小计，再套一层SUM(...) OVER (PARTITION BY dept ORDER BY month ROWS UNBOUNDED PRECEDING) - 注意
ROWS UNBOUNDED PRECEDING是显式声明范围，比默认行为更可靠；某些旧版 MySQL 窗口函数不支持省略范围，必须写全
如何让累计值对齐财务月报口径？
财务系统常要求“截至 2024-03 的累计 = 1月+2月+3月”，但数据库里的 month 字段可能是自然月（如 3 月 31 日记账），也可能是财年月（如财年从 4 月开始）。SUM OVER 本身不处理日历逻辑，得靠前置转换。
- 若需按财年累计（如 2024 财年=2024-04 至 2025-03），先用
CASE WHEN MONTH(date) >= 4 THEN YEAR(date) ELSE YEAR(date)-1 END AS fiscal_year提取财年，再用(fiscal_year * 100 + MONTH(date) - CASE WHEN MONTH(date) 构造可排序的财年月序号 - 避免在
ORDER BY中用函数表达式（如DATE_FORMAT(date, '%Y-%m')），部分数据库无法对其建索引，大表开窗会变慢；优先在 WHERE 或子查询中预计算好排序字段 - 测试时用
SELECT month, amount, SUM(amount) OVER (...) AS cum FROM ... ORDER BY month LIMIT 10直接看前几行，比查总数更容易发现跳变或断层
NULL 值和零预算月份怎么处理？
预算表里经常有“某月尚未录入预算”的空值，或者“本月预算为 0”的明确零值。SUM OVER 默认跳过 NULL，但不会自动补零——这意味着 2 月没数据，3 月累计就直接等于 3 月单月值，而非“1月+3月”。这不符合进度跟踪需求。
- 用
COALESCE(amount, 0)把 NULL 转成 0 参与计算，但注意：这只能解决“值为空”，不能解决“行缺失” - 真正缺失月份必须补行：用
SELECT DISTINCT month FROM calendar_table（维护一张含所有预算周期的维表）左连预算事实表，再对amount做COALESCE - 如果补零后累计值仍异常，检查是否误把
amount写成budget_amount（预算额）和actual_amount（实际消耗）混用——累计消耗进度必须基于实际发生值，不是预算值
最易被忽略的是：累计值是否要四舍五入？财务场景通常要求保留两位小数，但窗口函数内部计算若用浮点类型（如 FLOAT），可能在累加几十次后出现 0.001 级误差。务必在最终 SELECT 中用 ROUND(cum_sum, 2) 显式截断，别依赖前端格式化。
