用 SUM() OVER() 按月累计销售额需先按月聚合再开窗，确保 order_month 为规范 YYYY-MM 格式或日期类型，并显式指定 ROWS UNBOUNDED PRECEDING；MySQL 5.7/SQLite 等不支持窗口函数时可用自连接或相关子查询替代。
怎么用 SUM() OVER() 按月累计销售额
直接上手：用窗口函数 SUM() OVER() 是最简洁可靠的方式，前提是数据库支持（PostgreSQL、SQL Server、Oracle、MySQL 8.0+、BigQuery 等都行；SQLite 和旧版 MySQL 不支持）。关键不是“能不能算”，而是“怎么排好序再累加”——月份字段必须能正确排序，且不能有重复或缺失的月份粒度。
常见错误现象：SUM(sales) OVER (ORDER BY order_month) 算出来是“到当前行为止所有记录的累计”，但如果同一月份有多条记录，就会重复累加该月多笔销售，导致当月累计值虚高；更糟的是，如果 order_month 是字符串（如 '2023-1'），排序会变成字典序，'2023-10' 会排在 '2023-2' 前面。
- 确保月份字段是日期类型（如
DATE）或至少是规范的YYYY-MM字符串（长度固定、带前导零） - 用
GROUP BY先聚合到月粒度，再开窗，避免行级重复干扰：SELECT order_month, monthly_sales, SUM(monthly_sales) OVER (ORDER BY order_month ROWS UNBOUNDED PRECEDING) AS cum_sales FROM ( SELECT DATE_FORMAT(order_date, '%Y-%m') AS order_month, SUM(amount) AS monthly_sales FROM orders GROUP BY DATE_FORMAT(order_date, '%Y-%m') ) t; - 显式写
ROWS UNBOUNDED PRECEDING，别依赖默认行为——有些引擎默认是RANGE，遇到相同月份值会把同月所有行全包进来，逻辑易错
MySQL 5.7 或 SQLite 怎么办：没有窗口函数时的替代方案
没 OVER() 就得靠自连接或相关子查询，性能差、写法绕，但可行。核心思路是：对每一行“当前月份”，查出所有 ≤ 它的月份的销售总和。
使用场景：临时跑数、数据量小（
- MySQL 5.7 示例（假设已有
month_str CHAR(7)字段，格式为'2023-01'）：SELECT a.month_str, a.monthly_sales, (SELECT SUM(b.monthly_sales) FROM monthly_summary b WHERE b.month_str <= a.month_str) AS cum_sales FROM monthly_summary a ORDER BY a.month_str;
- 注意
month_str必须是固定格式（'2023-01'而非'2023-1'），否则字符串比较失效 - 务必给
month_str加索引，否则子查询每次都要全表扫
ORDER BY 里用 YEAR() + MONTH() 安不安全
不推荐。虽然看起来直观，但容易漏掉跨年边界或隐式类型转换问题。
比如 ORDER BY YEAR(order_date), MONTH(order_date) 在某些引擎中可能触发函数索引失效；更隐蔽的是，如果某行 order_date 为 NULL，整个累计序列可能从中间断掉（NULL 排序位置因引擎而异，MySQL 默认排最前，PostgreSQL 默认排最后）。
- 优先用原生日期截断：
DATE_TRUNC('month', order_date)（PostgreSQL）、STR_TO_DATE(CONCAT(YEAR(d), '-', MONTH(d), '-01'), '%Y-%m-%d')（MySQL） - 如果必须拆年月，至少包装成确定性表达式：
YEAR(order_date) * 100 + MONTH(order_date)，生成整数如202301，避免排序歧义 - 加
WHERE order_date IS NOT NULL显式过滤，别指望窗口函数自动跳过
累计值突然跳变？检查分区与去重逻辑
累计值在某个月份暴涨，大概率不是计算逻辑错，而是底层数据有重复或未去重。
典型诱因：订单表和订单明细表 join 后没去重，一条订单被多个商品行放大；或者按日汇总后再按月 group，但日期字段有时区/ETL 截断误差，导致同一天被分到两个月。
- 先验证月粒度数据是否干净：
SELECT order_month, COUNT(*) FROM monthly_summary GROUP BY order_month ORDER BY order_month;看单月记录数是否恒为 1 - 如果原始表是明细表，累计前务必确认是否已聚合：
SUM() OVER()不会帮你去重，它只忠实地累加输入的每一行 - 警惕 ETL 中的“补全月份”操作——人为插入 0 销售的月份行，会让累计值在该月不变，但下月会接着累加，造成“平台期”假象
实际写的时候，最容易被忽略的是月份字段的物理表示形式和NULL 处理。哪怕语法全对，一个没处理的 NULL 月份或一个少补零的 '2023-1'，都会让累计线在图表里突兀断开或倒退。
