sum() over() 按月累加结果不对的根本原因是原始数据缺失月份，窗口函数不自动补零；需先用日期维度或递归cte补全月份，再left join并coalesce(amount,0)后开窗累加。
为什么 SUM() OVER() 按月累加结果不对？
常见现象是：数据按年月分组后，SUM() OVER (ORDER BY year_month) 算出来的累计值跳变、重复或漏月。根本原因不是函数写错了，而是输入行本身没对齐「自然月粒度」——比如原始表里某个月缺失记录，窗口函数不会自动补 0，它只在现有行上排序累加。
解决思路很直接：先用日期维度表或递归 CTE 补全所有目标月份，再 LEFT JOIN 原始业务数据，最后对 COALESCE(amount, 0) 做窗口累加。
- 别直接对原始订单表或日志表跑
SUM() OVER()，除非你确认每月至少有一条记录 -
ORDER BY必须用可排序且无重复的月标识，推荐TO_CHAR(order_date, 'YYYY-MM')或DATE_TRUNC('month', order_date)（PostgreSQL） - 如果用
GROUP BY先聚合再开窗，注意ORDER BY的字段必须出现在SELECT或GROUP BY中，否则 MySQL 8.0+ 和 SQL Server 会报错
MySQL 8.0+ 实现按月累计销售额的最小可行代码
假设原始表叫 orders，有 order_date 和 amount 字段。以下语句能稳定产出 2023-01 到 2024-12 每月累计值：
WITH RECURSIVE months AS ( SELECT '2023-01'::DATE AS month_start UNION ALL SELECT month_start + INTERVAL 1 MONTH FROM months WHERE month_start <p>注意点：</p>
- MySQL 不支持
DATE_TRUNC，统一用DATE_FORMAT(..., '%Y-%m')对齐月粒度 -
ROWS UNBOUNDED PRECEDING显式声明范围，避免某些版本默认行为不一致 - CTE 里的
::DATE是 PostgreSQL 写法，MySQL 要改成STR_TO_DATE('2023-01', '%Y-%m')
PostgreSQL 中 generate_series() 更简洁地补月
不用手写递归 CTE，直接用内置函数生成连续月份序列，更可靠也更易读：
SELECT
TO_CHAR(d.month, 'YYYY-MM') AS ym,
COALESCE(m.total, 0) AS monthly_amount,
SUM(COALESCE(m.total, 0)) OVER (ORDER BY d.month) AS cum_amount
FROM generate_series('2023-01-01'::DATE, '2024-12-01'::DATE, '1 month') AS d(month)
LEFT JOIN (
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS total
FROM orders
WHERE order_date >= '2023-01-01'
GROUP BY DATE_TRUNC('month', order_date)
) m ON d.month = m.month
ORDER BY d.month;
关键差异：
-
generate_series()返回的是DATE类型，和DATE_TRUNC('month', ...)对齐天然匹配，不用字符串转换 - WHERE 条件提前过滤原始数据，避免大表全扫；但补月范围必须覆盖所有可能需要的月份，不能依赖原始数据的最大/最小时间
- 如果累计值要支持「截至当月的最近 12 个月滚动和」，就把
SUM(...) OVER (... ROWS BETWEEN 11 PRECEDING AND CURRENT ROW)
SQL Server 怎么处理带时区的订单日期？
当 order_date 是 DATETIMEOFFSET 类型时，直接 YEAR(order_date) 或 MONTH(order_date) 会忽略时区，导致跨 UTC+8 和 UTC-5 的订单被分到错误月份。正确做法是先用 AT TIME ZONE 标准化：
- 先转成目标时区：
order_date AT TIME ZONE 'China Standard Time' - 再截取月份：
DATEFROMPARTS(YEAR(...), MONTH(...), 1)或直接FORMAT(..., 'yyyy-MM')（但后者不可 SARGable） - 窗口函数中
ORDER BY必须用确定性表达式，避免用FORMAT()—— 改用YEAR()*100 + MONTH()生成整数序号更稳妥
真正容易被忽略的点是：补月逻辑和时区转换必须在同一个上下文中完成，否则 LEFT JOIN 时两边月标识看似一样，实则因时区偏差错位。比如北京时间 2023-02-01 00:30，在 UTC 是 2023-01-31 16:30 —— 如果没统一转时区，这个订单会被算进 1 月而非 2 月。
