MySQL按月累计统计：从子查询到窗口函数的完整方案与性能对比-开发者社区

1. 从业务场景说起：为什么需要“逐月累加”？

在数据分析和报表开发中，我们经常会遇到一类需求：不仅要看每个月的独立业绩，还要看截止到某个月份的累计业绩。比如，销售部门需要看“截至3月底的年度累计销售额”，产品运营需要看“用户从上线至今的月度累计留存”，财务需要看“本年度各月的累计利润”。

这种“按月统计，并逐月累加”的需求，在SQL中通常被称为“Running Total”或“累计求和”。在MySQL里实现它，乍一看似乎很简单，不就是先GROUP BY月份，然后再把前面的月份数据加起来吗？但当你真正动手去写，尤其是在处理海量数据、考虑性能、处理空月份或者需要多维度组合统计时，就会发现里面有不少门道。不同的写法在逻辑清晰度、执行效率和场景适应性上差异巨大。

今天，我就结合自己多年在报表系统和数据分析后台的实战经验，系统梳理一下在MySQL中实现按月累计统计的几种典型写法。我们会从最基础的子查询和自连接开始，讲到更现代的窗口函数，最后再聊聊在特殊业务场景下的变量技巧和预聚合优化思路。无论你是刚接触SQL不久的新手，还是希望优化现有报表性能的老手，相信都能从中找到有用的东西。

2. 基础数据准备与问题定义

在深入各种写法之前，我们先明确一下要解决的问题，并构造一个标准的数据集用于后续所有示例的演示。清晰的问题定义是写好SQL的第一步。

假设我们有一张销售记录表sales_records，它记录了每一笔订单的详细信息。为了聚焦于“按月累计”这个核心问题，我们只关心其中三个字段：

id: 订单唯一标识（无关紧要，仅用于区分记录）。
sale_amount: 销售额，这是我们要求和的数值。
sale_date: 销售日期，我们需要从这个日期中提取出“年月”来进行分组。

我们的核心目标是：统计出每个月的总销售额，并计算出从最早有记录的月份开始，到当前月份的累计销售额。

首先，创建测试表并插入一些数据：

-- 创建销售记录表 CREATE TABLE sales_records ( id INT PRIMARY KEY AUTO_INCREMENT, sale_amount DECIMAL(10, 2) NOT NULL, sale_date DATE NOT NULL, INDEX idx_sale_date (sale_date) -- 为日期字段建立索引，这对后续查询性能至关重要 ); -- 插入示例数据，覆盖多个年份和月份，并让数据量有一定规模 INSERT INTO sales_records (sale_amount, sale_date) VALUES (100.00, '2023-01-05'), (150.00, '2023-01-15'), (200.00, '2023-02-10'), (250.00, '2023-02-20'), (300.00, '2023-03-08'), (120.00, '2023-04-12'), (180.00, '2023-04-25'), -- 4月数据稍多 (90.00, '2023-05-30'), -- 5月数据较少 -- 模拟2024年数据 (400.00, '2024-01-15'), (350.00, '2024-01-25'), (500.00, '2024-02-05'), (150.00, '2024-03-20'), (250.00, '2024-03-28'), -- 故意插入一些跨年数据，测试逻辑是否健壮 (600.00, '2022-12-28');

现在，如果我们只做简单的月度统计，SQL很简单：

SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month;

查询结果可能如下：

month	monthly_amount
2022-12	600.00
2023-01	250.00
2023-02	450.00
2023-03	300.00
2023-04	300.00
2023-05	90.00
2024-01	750.00
2024-02	500.00
2024-03	400.00

接下来，我们的任务就是在这个结果的基础上，新增一列cumulative_amount，它应该是这样计算的：

2022-12: 600.00 (第一个月，累计就是本月)
2023-01: 600.00 + 250.00 = 850.00
2023-02: 850.00 + 450.00 = 1300.00
... 以此类推。

下面，我们就开始逐一拆解实现这个目标的几种方法。

3. 方法一：使用关联子查询

这是最直观、最容易理解的一种方法，尤其适合SQL初学者来理解“累计”的本质。它的核心思想是：对于结果集中的每一行（代表一个月份），都去计算所有“日期小于等于该月份”的记录的总和。

3.1 基础写法与原理

SELECT a.month, a.monthly_amount, ( SELECT SUM(b.monthly_amount) FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) b WHERE b.month <= a.month ) AS cumulative_amount FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) a ORDER BY a.month;

原理解析：

最内层的子查询（我们称之为基础聚合子查询）先计算出每个月的独立销售额monthly_amount。这个子查询被执行了一次，生成了月度汇总的中间结果。
外层查询从这个中间结果a中取出每一行数据。
对于a中的每一行，关联子查询(SELECT SUM(b.monthly_amount) ... WHERE b.month <= a.month)都会执行一次。它的作用是：从同样的月度汇总中间结果b中，筛选出所有月份编号（b.month）小于等于当前行月份编号（a.month）的记录，然后对这些记录的monthly_amount再次求和。这个“再次求和”的结果，就是截止到当前月份的累计销售额。

注意：这里为什么用b.month <= a.month？因为month字段是‘%Y-%m’格式的字符串，如‘2023-01’。在字符串比较时，‘2023-01’ <= ‘2023-02’ 是成立的，这正好符合时间顺序。这是该方法成立的关键前提。

3.2 性能分析与适用场景

这种写法的优点是逻辑极其清晰，一眼就能看懂“累计”是怎么算出来的。但它有一个致命的缺点：性能差。

假设月度汇总结果有N行（例如100个月），那么：

外层查询需要处理N行。
对于外层每一行，关联子查询都要几乎遍历整个月度汇总结果（平均N/2行）来进行求和。
总的计算复杂度大约是 O(N²)。当N很大时（比如统计过去10年，有120个月），查询速度会急剧下降。

所以，这种方法的适用场景非常有限：

数据量极小：比如只统计最近几个月，或者只是临时在开发环境验证一下逻辑。
逻辑验证与教学：作为理解累计求和概念的入门示例是极好的。
MySQL版本过低（< 8.0）且无法使用变量：在没有窗口函数的旧版本中，如果不想用变量（变量写法有坑，后面会讲），这可能是一种备选，但必须严格限制数据量。

实操心得：在早期的项目中，我曾用这种方式生成过一份年度报表，当时数据只有几十行，跑起来很快。后来业务数据增长到几百行，页面加载时间就从1秒变成了10秒以上，直接导致了超时。这是一个典型的“开发时跑得通，上线后扛不住”的坑。记住：只要你的月度数据可能超过100行，就绝对不要在生产环境使用这种关联子查询写法。

4. 方法二：使用自连接

自连接是关联子查询的一种“展开”形式，它通过将表与自身连接，来显式地表达行与行之间的关系。对于累计求和，我们可以通过连接条件将“当前月”与所有“过去月”关联起来。

4.1 通过笛卡尔积与条件过滤实现

SELECT a.month, a.monthly_amount, SUM(b.monthly_amount) AS cumulative_amount FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) a JOIN ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) b ON b.month <= a.month GROUP BY a.month, a.monthly_amount ORDER BY a.month;

原理解析：

我们创建了两个完全相同的月度汇总子查询，别名为a和b。
通过ON b.month <= a.month进行连接。这意味着对于a表中的每一行（当前月），b表中所有月份小于等于它的行都会与之匹配。例如，a表是‘2023-03’时，b表会匹配‘2022-12’， ‘2023-01’， ‘2023-02’， ‘2023-03’。
最后，我们按照a.month和a.monthly_amount进行分组，并对所有匹配到的b.monthly_amount进行求和(SUM(b.monthly_amount))，从而得到累计值。

4.2 与关联子查询的对比

这种方法在逻辑上和关联子查询是完全等价的，可以看作是它的另一种表达。但在大多数MySQL版本的实际执行中，它的性能通常比关联子查询还要差。

为什么？因为关联子查询虽然次数多，但每次子查询操作的数据集是明确的（整个b表）。而自连接，特别是带有不等条件(<=)的连接，很容易生成一个巨大的中间结果集（笛卡尔积的过滤版），这个中间结果集的行数大约是 N*(N+1)/2，然后再对这个巨大的集合做分组聚合，对内存和CPU都是巨大的考验。

性能排序（从差到更差）：关联子查询 < 自连接。

一个重要的注意事项：注意GROUP BY子句是GROUP BY a.month, a.monthly_amount。这里必须把a.monthly_amount也加进去。因为在SQL标准中，SELECT列表里出现的非聚合列（这里就是a.monthly_amount），必须出现在GROUP BY子句中，否则结果可能不确定（取决于数据库的SQL模式）。虽然在某些MySQL配置下只写a.month可能也能运行，但为了代码的严谨性和可移植性，强烈建议将SELECT中所有非聚合列都进行分组。

适用场景：理论上，它可以用于所有关联子查询适用的场景。但在实践中，除非有特殊原因（比如某些古老数据库优化器对自连接有神秘优化），否则不推荐使用。它既没有关联子查询直观，性能又更差，属于“两头不讨好”的写法。

5. 方法三：使用用户变量

在MySQL 8.0引入窗口函数之前，用户变量是高性能实现累计求和的主流“黑科技”。它的思路是模仿程序中的循环：按顺序遍历排好序的月度数据，用一个变量来保存运行中的累计值，并逐行输出。

5.1 经典变量累加写法

SELECT month, monthly_amount, @cumulative := @cumulative + monthly_amount AS cumulative_amount FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month -- 排序至关重要！ ) t CROSS JOIN (SELECT @cumulative := 0) vars ORDER BY month;

原理解析：

CROSS JOIN (SELECT @cumulative := 0) vars：这是一个初始化用户变量@cumulative的技巧。通过交叉连接，确保主查询的每一行都能访问到这个已初始化为0的变量。
子查询t：首先按月份顺序获取每个月的销售额。这里的ORDER BY month是灵魂！必须保证数据按照时间顺序处理，累计才有意义。
主查询SELECT：对于t中的每一行（按顺序），执行@cumulative := @cumulative + monthly_amount。这是一个赋值表达式，它先计算当前变量值加上本月销售额，然后将结果赋回给@cumulative，并作为cumulative_amount列输出。这个过程就像在遍历一个有序数组并累加。

5.2 变量的巨大隐患与严格使用规范

变量写法性能极高，复杂度是O(N)，因为它只扫描了排好序的月度数据一次。但是，它充满了陷阱，在MySQL官方文档中，对用户变量在SELECT语句中的求值顺序有明确的警告，指出其顺序是“未定义的”。

这意味着，即使你写了ORDER BY，MySQL优化器也可能在最终组合结果集之前，以它认为更优的顺序来求值@cumulative，从而导致累计结果错乱。虽然在很多简单查询中它“看起来”工作正常，但一旦查询变得复杂（例如包含JOIN、UNION或子查询），或者MySQL版本/优化器策略发生变化，结果就可能出错。

安全使用变量的“铁律”：如果一定要用，必须遵循最保守、最明确的写法，将计算过程完全封装在一个确定顺序的派生表中：

SELECT month, monthly_amount, @cumulative := @cumulative + monthly_amount AS cumulative_amount FROM ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month ) t, (SELECT @cumulative := 0) vars;

注意这里使用了老式的逗号连接语法,，它和CROSS JOIN是等价的。关键点在于：变量初始化和累加计算必须在同一个查询层级、同一条语句中完成，避免优化器打乱顺序。

即便如此，仍然不推荐在新项目中使用。它的可读性差，维护成本高，且存在潜在风险。仅在MySQL 5.7等旧版本环境中，且对性能有极端要求，并经过充分测试的情况下，方可谨慎使用。

踩坑实录：我曾维护过一个旧系统，报表SQL用了变量计算累计值，一直运行良好。后来为了优化另一个部分，给表增加了一个复合索引。就是这个索引，改变了查询的执行计划，导致变量累加的顺序发生了微妙变化，报表数字连续几天对不上，排查了整整一天才找到这个原因。从此以后，我对变量写法敬而远之。

6. 方法四：使用窗口函数

MySQL 8.0 终于引入了标准的窗口函数，这彻底改变了复杂报表SQL的写法。对于累计求和，我们可以使用SUM(...) OVER (ORDER BY ...)这种简洁、强大且标准的方式。

6.1 基础窗口函数写法

SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount, SUM(SUM(sale_amount)) OVER ( ORDER BY DATE_FORMAT(sale_date, '%Y-%m') ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month;

原理解析：

SUM(sale_amount) ... GROUP BY ...：这部分和之前一样，先计算每个月的独立销售额。
SUM(SUM(sale_amount)) OVER (...)：这是窗口函数的核心。
- 外层的SUM()是一个窗口聚合函数，它不是在分组后计算一次，而是为每一行计算一个值。
- 它的参数是内层的SUM(sale_amount)，也就是每月的销售额。
- OVER子句定义了窗口的范围：ORDER BY DATE_FORMAT(sale_date, '%Y-%m')指定了数据按月份排序。
- ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW指定了窗口的框架：从结果集的第一行（UNBOUNDED PRECEDING）到当前行（CURRENT ROW）。这个框架内的所有行的monthly_amount值，将被用于这次窗口求和计算。
因此，对于每一行，cumulative_amount的计算方式就是：从最早月份开始，到当前月份为止，所有月份的monthly_amount之和。完美实现了累计。

6.2 窗口函数的优势与细节探讨

优势：

声明式，易读易维护：你直接告诉数据库“我要从开头累加到当前行”，而不是教数据库如何一步步去连接或循环。意图清晰。
高性能：MySQL优化器会对窗口函数进行专门优化，通常比关联子查询和自连接快几个数量级，与变量写法性能相当甚至更优，且没有变量的风险。
标准SQL：这是ANSI SQL标准语法，可移植性强。
功能强大：窗口函数不止能做累计求和，还能做移动平均、排名、前后行对比等，学会这一个，解决一大片问题。

关于窗口框架ROWS BETWEEN ...：在上面的例子中，我们显式指定了ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。实际上，对于SUM/AVG等聚合窗口函数，当OVER子句中只有ORDER BY而没有指定框架时，默认的框架就是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。RANGE和ROWS在处理并列值（同一个月有多条汇总记录？在我们场景里不会，因为GROUP BY了）时有所不同。为了绝对清晰和避免歧义，尤其是在处理金额、数量等需要精确累计的场景，我建议总是显式地写上ROWS BETWEEN ...框架。

因此，上面的SQL可以简化为（依赖默认框架），但更推荐显式写法：

-- 简化写法（依赖默认框架） SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount, SUM(SUM(sale_amount)) OVER (ORDER BY DATE_FORMAT(sale_date, '%Y-%m')) AS cumulative_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month;

处理跨年或多维度累计窗口函数的强大之处在于可以轻松处理复杂需求。比如，我们想要每年重新开始累计（即年度累计），只需要在OVER子句中加入PARTITION BY：

SELECT YEAR(sale_date) AS year, DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount, SUM(SUM(sale_amount)) OVER ( PARTITION BY YEAR(sale_date) -- 按年分区，每年独立累计 ORDER BY DATE_FORMAT(sale_date, '%Y-%m') ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount_in_year FROM sales_records GROUP BY YEAR(sale_date), DATE_FORMAT(sale_date, '%Y-%m') ORDER BY year, month;

适用场景：只要你的MySQL是8.0或以上版本，窗口函数就是实现累计统计的首选和唯一推荐方案。它平衡了性能、可读性、安全性和功能性。

7. 方法五：使用CTE与窗口函数组合

公共表表达式本身不提供新的累计计算能力，但它能让复杂的窗口函数查询变得更加清晰、易于调试和复用。特别是当你的累计逻辑需要基于一个已经比较复杂的查询结果时，CTE的优势就体现出来了。

7.1 利用CTE增强可读性

回顾一下方法四中直接使用的窗口函数，SUM(SUM(sale_amount))这种嵌套聚合可能让一些人觉得有点绕。我们可以用CTE将其分步拆解：

WITH monthly_sales AS ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) SELECT month, monthly_amount, SUM(monthly_amount) OVER ( ORDER BY month ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount FROM monthly_sales ORDER BY month;

原理解析：

WITH monthly_sales AS (...)：定义了一个名为monthly_sales的CTE。这个CTE就像一个临时的视图，它只做一件事——计算每个月的销售额。这一步逻辑独立且清晰。
主查询直接从monthly_sales这个“干净”的中间结果中选取数据。
在主查询中，我们使用窗口函数SUM(monthly_amount) OVER (...)进行累计。因为数据源已经是聚合好的月度数据，所以窗口函数直接对monthly_amount列操作即可，不再需要嵌套聚合，逻辑更直白。

7.2 CTE在复杂累计场景下的威力

CTE的真正价值体现在多步骤、多层次的复杂统计中。假设我们有一个更变态的需求：先按销售员和月份统计销售额，然后计算每个销售员自己月度销售额的累计，最后再列出所有累计额超过10万的记录。

不用CTE的写法会非常嵌套和混乱。而用CTE可以写成：

WITH salesperson_monthly AS ( SELECT salesperson_id, DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY salesperson_id, DATE_FORMAT(sale_date, '%Y-%m') ), salesperson_cumulative AS ( SELECT salesperson_id, month, monthly_amount, SUM(monthly_amount) OVER ( PARTITION BY salesperson_id ORDER BY month ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS personal_cumulative FROM salesperson_monthly ) SELECT * FROM salesperson_cumulative WHERE personal_cumulative > 100000 ORDER BY salesperson_id, month;

通过两个CTE，我们将问题分解成了三个清晰的步骤：

salesperson_monthly: 计算每人每月销售额。
salesperson_cumulative: 基于上一步，计算每人各自的累计额。
主查询：从累计结果中筛选。

这种写法不仅易于编写和阅读，也更易于调试。你可以单独运行每一个CTE来验证中间结果。

适用场景：

查询逻辑复杂：当累计计算需要基于一个多表JOIN、多层过滤或复杂聚合的结果时。
需要代码复用：同一个中间结果（如月度汇总）可能被后续多个查询用到。
追求代码清晰度和可维护性：对于团队协作或长期维护的项目，清晰的逻辑分层至关重要。

实操心得：在处理一个涉及用户行为链路的漏斗分析报表时，我需要先计算每个步骤的日UV，然后计算步骤间的转化率，最后再计算转化率的7日移动平均。如果不用CTE，一条SQL会写成“俄罗斯套娃”，根本没法维护。我果断使用了三层CTE，每一层只做一个明确的转换，最后主查询简单明了。后来需求变更，只需要改其中一个CTE的逻辑，非常方便。CTE是编写复杂分析SQL的“最佳伴侣”。

8. 高级话题：性能优化与边缘情况处理

掌握了核心写法，我们还需要关注生产环境中可能遇到的实际问题：数据量大了怎么办？月份不连续怎么办？如何应对更复杂的业务逻辑？

8.1 面对海量数据的优化策略

当原始表sales_records有上亿行记录时，即使使用窗口函数，直接GROUP BY DATE_FORMAT(sale_date, '%Y-%m')也可能很慢，因为需要全表扫描并计算哈希聚合。

策略一：利用索引与预聚合最好的优化是从数据源头减少计算量。

确保sale_date上有索引：这能加速分组和排序。对于我们的查询，一个(sale_date, sale_amount)的复合索引可能效果更好，因为索引覆盖了查询所需的所有列。
使用预聚合表：如果实时性要求不是秒级，可以建立一张“月度汇总表”，在每天或每小时通过定时任务（如Event或调度系统）更新。这样，累计查询就直接基于这张只有几百行的小表进行，性能飞升。

-- 创建月度汇总表 CREATE TABLE sales_monthly_summary ( year_month CHAR(7) PRIMARY KEY, -- 格式‘YYYY-MM’ total_amount DECIMAL(15, 2) NOT NULL, last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 定时任务更新语句（增量更新示例） INSERT INTO sales_monthly_summary (year_month, total_amount) SELECT DATE_FORMAT(sale_date, '%Y-%m'), SUM(sale_amount) FROM sales_records WHERE sale_date >= CURDATE() - INTERVAL 1 DAY -- 仅处理新增数据 GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ON DUPLICATE KEY UPDATE total_amount = VALUES(total_amount), last_updated = CURRENT_TIMESTAMP; -- 基于预聚合表的累计查询 SELECT year_month AS month, total_amount AS monthly_amount, SUM(total_amount) OVER (ORDER BY year_month) AS cumulative_amount FROM sales_monthly_summary ORDER BY year_month;

策略二：分阶段计算如果必须实时查询大表，可以尝试将窗口函数的计算拆解。先通过子查询或CTE利用索引快速完成月度聚合（这个阶段数据量已大幅减少），再将这个小型结果集交给窗口函数处理。我们之前写的CTE版本其实就隐含了这种思想。

8.2 处理缺失月份与自定义起始点

业务数据可能有月份缺失（如某个月没有任何销售）。我们的查询结果中就不会出现这个月，导致累计曲线在时间轴上“跳跃”。有时业务方希望看到连续的月份，即使销售额为0。

生成连续月份序列：我们可以利用递归CTE（MySQL 8.0+）或数字辅助表，生成一个连续的日期序列，再左联我们的销售数据。

WITH RECURSIVE date_series AS ( SELECT DATE('2022-01-01') AS month_start -- 起始日期 UNION ALL SELECT DATE_ADD(month_start, INTERVAL 1 MONTH) FROM date_series WHERE month_start < CURDATE() -- 结束日期 ), monthly_sales AS ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS year_month, SUM(sale_amount) AS monthly_amount FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) SELECT DATE_FORMAT(ds.month_start, '%Y-%m') AS month, COALESCE(ms.monthly_amount, 0) AS monthly_amount, -- 处理空值 SUM(COALESCE(ms.monthly_amount, 0)) OVER ( ORDER BY ds.month_start ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_amount FROM date_series ds LEFT JOIN monthly_sales ms ON DATE_FORMAT(ds.month_start, '%Y-%m') = ms.year_month ORDER BY ds.month_start;

自定义累计起始点：有时累计不是从最早数据开始，而是从财年开始、从活动开始日等。这可以通过在窗口函数中调整ORDER BY和框架的起始点来实现，但更简单的方法是在生成基础数据时进行过滤。

-- 只计算从‘2023-04-01’开始的累计 WITH filtered_sales AS ( SELECT sale_date, sale_amount FROM sales_records WHERE sale_date >= '2023-04-01' ), monthly_sales AS ( SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount FROM filtered_sales GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ) SELECT ... -- 窗口函数累计逻辑同上

8.3 多维度组合累计与条件累计

累计不仅可以对“所有历史”进行，还可以在多个维度上灵活组合。

按维度分区累计：前面已经提到过PARTITION BY，它可以实现按销售员、按产品类别、按地区等多个维度的独立累计。

SELECT sales_region, DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount, SUM(SUM(sale_amount)) OVER ( PARTITION BY sales_region -- 每个区域独立累计 ORDER BY DATE_FORMAT(sale_date, '%Y-%m') ) AS region_cumulative, SUM(SUM(sale_amount)) OVER ( -- 不分区，全局累计 ORDER BY DATE_FORMAT(sale_date, '%Y-%m') ) AS global_cumulative FROM sales_records GROUP BY sales_region, DATE_FORMAT(sale_date, '%Y-%m') ORDER BY sales_region, month;

条件累计：例如，我们只想累计“销售额大于100的月份”。这需要在窗口函数内部使用条件聚合。

SELECT DATE_FORMAT(sale_date, '%Y-%m') AS month, SUM(sale_amount) AS monthly_amount, SUM( CASE WHEN SUM(sale_amount) > 100 THEN SUM(sale_amount) ELSE 0 END ) OVER ( ORDER BY DATE_FORMAT(sale_date, '%Y-%m') ) AS cumulative_amount_gt_100 FROM sales_records GROUP BY DATE_FORMAT(sale_date, '%Y-%m') ORDER BY month;

注意，这里CASE WHEN判断的是内层聚合函数SUM(sale_amount)的结果（即月销售额），然后窗口函数SUM再对这个条件结果进行累计。这种嵌套聚合需要仔细理解执行顺序。

9. 总结与最终选择建议

走过了从古老低效的关联子查询，到危险但快速的变量，再到现代优雅的窗口函数，我们看到了实现同一个需求的技术演进。最后，我们来做个清晰的对比，并给出最直接的选型建议。

方法对比一览表

特性/方法	关联子查询	自连接	用户变量	窗口函数 (MySQL 8.0+)	CTE + 窗口函数
逻辑清晰度	高	中	低	高	极高
代码可读性	中	低	低	高	高
执行性能	差 (O(N²))	极差 (O(N²))	优 (O(N))	优 (O(N))	优 (O(N))
结果确定性	高	高	低 (有风险)	高	高
SQL标准	是	是	否 (MySQL特性)	是 (SQL:2003)	是 (SQL:1999/2003)
功能扩展性	差	差	差	强	强
推荐指数	⭐	不推荐	⭐⭐ (仅限旧版本)	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐ (复杂时)

最终选择建议（一句话版）：

如果你的MySQL版本 >= 8.0，无脑选择【窗口函数】。如果查询逻辑复杂，用【CTE + 窗口函数】拆解。

详细决策路径：

MySQL 8.0 或更新版本：
- 简单累计：直接使用SUM(...) OVER (ORDER BY ...)。这是标准、高效、安全的首选。
- 复杂逻辑或多步骤：使用CTE将中间结果命名化，再结合窗口函数。这大幅提升了代码的可读性、可调试性和可维护性。
MySQL 5.7 或更旧版本：
- 首要任务：强烈建议推动升级到MySQL 8.0+。窗口函数带来的开发效率和运行性能提升是全方位的。
- 无法升级时：
  - 如果数据量很小（比如后台管理页面查看少量数据），可以考虑使用关联子查询，但务必清楚其性能瓶颈。
  - 如果对性能有苛刻要求，且能承担潜在风险，可以极其谨慎地使用用户变量，并必须遵循“单语句内初始化与计算”的铁律，并进行充分测试。任何表结构、索引或优化器版本的变动都可能引入风险。
  - 探索是否能在应用层（Java, Python等）进行累计计算，将复杂的累计逻辑从数据库转移到业务代码中。

个人经验与避坑指南：

索引是基础：无论用哪种方法，在sale_date以及分组字段上建立合适的索引，是保证性能的底线。
理解业务边界：累计是从何时开始？是否按财年重置？是否包含未发生的未来月份？是否处理数据缺失？在写SQL前，务必和业务方确认清楚这些边界条件。
测试空数据：你的SQL在没有任何销售数据的月份，或者整张表为空时，会返回什么？是空结果集，还是0？确保行为符合预期。
窗口函数框架是细节：记住ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这个框架，显式写出它，避免因默认行为 (RANGE) 在遇到相同排序值时产生的意外情况。

按月累计求和是一个经典的SQL问题，它像一把钥匙，打开了一扇通往更高级数据分析的大门。从最初的蛮力计算，到利用变量的小聪明，再到窗口函数的降维打击，我们不仅看到了SQL语法的发展，更看到了思维模式的转变：从“如何命令数据库一步步操作”到“如何声明我想要的结果”。掌握窗口函数，无疑是现代数据分析师和后台开发工程师的一项核心技能。