从报表需求认识 ROLLUP：它到底解决了什么问题

做后台管理系统或者报表导出的时候，我猜你大概率遇到过这种场景：运营要一张表，里面既要看到每一个品类、每一个月的销售额，又要在每段后面跟上小计，最后还要有一个总计行。第一反应就是写 GROUP BY，然后拿到数据在前端挨个算，或者干脆查三次 SQL 再拼结果。麻烦不说，数据不一致的风险还一直悬着。其实 MySQL 很早就给了答案，就是标题里这个 ROLLUP。

ROLLUP 是 GROUP BY 的一个扩展选项，名字直译是"上卷"。它的作用是在分组统计的基础上，自动往上多算一层汇总。比如 GROUP BY 某个字段只能得到明细分组，加上 WITH ROLLUP 之后，会把所有分组的合计、以及更粗粒度层级的小计也一起算出来。换句话说，一条 SQL 就能把"明细分组 + 小计 + 总计"全部带回来，前端直接渲染，后端不用再做二次聚合。

这篇文章适合谁？一类是刚接触聚合查询、对 GROUP BY 进阶用法还不熟的新手，另一类是写报表 SQL 写到想骂人的业务开发。我会从基础语法开始，把它的结果集规律、怎么区分汇总行、以及几个容易踩的坑一次性讲透。

1. 先建立实验环境：一张销售明细表

讲 SQL 不能空对空，我们先把实验表建出来。下面这张表模拟了一个简单的线上销售场景，包含订单 ID、销售日期、所属区域、产品类目、销售额这几个字段。

sql复制CREATE TABLE sales (
    id INT PRIMARY KEY AUTO_INCREMENT,
    sale_date DATE NOT NULL,
    region VARCHAR(20) NOT NULL,
    category VARCHAR(20) NOT NULL,
    amount DECIMAL(10,2) NOT NULL
);

插入几行模拟数据，注意数据要覆盖多个日期、多个区域、多个类目，后面跑 ROLLUP 才看得清结果：

sql复制INSERT INTO sales (sale_date, region, category, amount) VALUES
('2024-01-05', '华东', '数码', 3200.00),
('2024-01-12', '华东', '家电', 5400.00),
('2024-01-18', '华北', '数码', 2100.00),
('2024-01-25', '华北', '服装', 1800.00),
('2024-02-03', '华东', '数码', 4300.00),
('2024-02-08', '华南', '家电', 6200.00),
('2024-02-14', '华南', '服装', 2500.00),
('2024-02-21', '华北', '数码', 3900.00),
('2024-03-02', '华东', '服装', 1600.00),
('2024-03-11', '华南', '数码', 4800.00),
('2024-03-20', '华北', '家电', 5100.00),
('2024-03-27', '华东', '家电', 3600.00);

字段不多，但足够演示单列分组、多列分组、时间维度汇总这些典型场景。下面所有示例都会基于这份数据运行，你可以直接复制到本地 MySQL 8.0 环境里跑。

提示：这里选用 MySQL 8.0 版本，8.0 对 GROUP BY 相关语法支持完善，而且引入了 GROUPING() 函数，对区分汇总行非常有用。MySQL 5.7 及更低版本也支持 ROLLUP，但没有 GROUPING()，后面会专门说怎么兼容。

2. 基础语法与结果集规律：一条 SQL 拿到分组+汇总

2.1 基本用法：GROUP BY 后加 WITH ROLLUP

先看最常见的写法。假设我们要按照产品类目统计销售额，并且需要知道所有类目的销售总额：

sql复制SELECT category, SUM(amount) AS total_amount
FROM sales
GROUP BY category WITH ROLLUP;

执行结果会是这样：

注意看最后一行，category 字段是 NULL，total_amount 是所有类目的总计。这就是 ROLLUP 的行为：在普通分组行之外，额外追加一行所有数据的聚合结果。NULL 出现在被分组的列上，是"这场分组不存在了"的标志。

2.2 多列分组的层级汇总逻辑

ROLLUP 更有价值的是在多列分组的时候。它会按照 GROUP BY 列从左到右的顺序，逐级"减少一列"再做汇总。比如按区域和类目两列分组：

sql复制SELECT region, category, SUM(amount) AS total_amount
FROM sales
GROUP BY region, category WITH ROLLUP;

结果集分为三层：

第一层：region 和 category 都明确，是每个区域下每个类目的明细小计。
第二层：region 有值、category 为 NULL，是每个区域自己的区域合计。
第三层：region 和 category 都为 NULL，是全局总计。

这就是 ROLLUP 最经典的层级模式，我在后面用一个完整结果表来展示：

这个结果包含三层汇总，而且自动按照 region 排序后把汇总行插在了每组后面。换句话说，ROLLUP 帮你做了分组内小计和全局总计，不需要写 UNION ALL 去拼接多个查询。

2.3 三列及更多列的汇总层级

参与分组的列越多，ROLLUP 生成的汇总行也就越多。以三列 GROUP BY a, b, c WITH ROLLUP 为例，它会生成：

• GROUP BY a, b, c 的明细分组行
• GROUP BY a, b 的小计行，表现为 c 为 NULL
• GROUP BY a 的合计行，表现为 b、c 为 NULL
• 空分组的总计行，表现为 a、b、c 都为 NULL

这里有一个规律值得记下来：N 个分组列会生成 N+1 层结果。从最细粒度逐级向上，每次从最右边拿掉一列参与汇总，直到完全无分组的全局总计。理解这个递推关系，多列场景就不容易懵。

3. NULL 汇总行与真实 NULL 值的冲突：必须解决的问题

看到这里可能有人会问：我用 GROUPING SETS 或者手工 UNION ALL 也能拼出类似结果，凭什么用 ROLLUP？答案是简洁，但代价是结果集里出现的一堆 NULL 很容易造成误判。

3.1 为什么直接用 NULL 判断不靠谱

ROLLUP 产生的汇总行，在最右侧参与分组但已经被"上卷"掉的列上会用 NULL 填充。可问题是，业务数据里本身就可能存在 NULL 值。假设 category 字段允许为空，某几行销售记录确实没有类目，此时普通分组行 category 为 NULL，汇总行的 category 也为 NULL，光看结果无法区分二者。

举个更实际的例子：如果 region 表里有一个真值为 NULL 的区域，加上 ROLLUP 汇总行里 region 为 NULL，我们在 Java 或者前端渲染的时候，就没办法准确地决定这一行到底是"具体数据"还是"汇总数据"。

3.2 GROUPING() 函数的正确姿势

MySQL 8.0 提供的 GROUPING() 函数就是专门用来解决这个识别问题的。它接受一个列名作为参数，当该行是 ROLLUP 生成的汇总行时返回 1，否则返回 0。比如：

sql复制SELECT
    region,
    category,
    GROUPING(region) AS grp_region,
    GROUPING(category) AS grp_category,
    SUM(amount) AS total_amount
FROM sales
GROUP BY region, category WITH ROLLUP;

结果中的 grp_category 字段：明细行为 0，区域小计行为 1。grp_region 字段：全局总计行为 1。这样我们就能用 CASE WHEN 把 NULL 替换成"小计"、"总计"这样的语义化标签，而不是把真正的 NULL 值和汇总行混在一起。

3.3 如何在低版本 MySQL 上兼容

如果你的项目还在用 MySQL 5.7 或更低版本，GROUPING() 函数不可用，只能用 GROUP BY 列是否为 NULL 来做判断。这里要求参与分组的列在建表时就定义为 NOT NULL，否则会有误判风险。如果业务表本身允许 NULL，建议先用 COALESCE 或者 CASE WHEN 把真实 NULL 替换成特殊标记，再配合"分组列 IS NULL"判断。不过老实说，升级到 MySQL 8.0 才是长期方案。

4. 实战案例：月度销售报表怎么用 ROLLUP 一次查出来

4.1 按月份统计并输出每月合计和整体总计

运营报表里最常遇到的需求就是"每月每类目的销售数据，还要有月度合计和总计"。这个需求可以用 DATE_FORMAT 提取月份，然后与 category 联合分组：

sql复制SELECT
    DATE_FORMAT(sale_date, '%Y-%m') AS month,
    category,
    SUM(amount) AS total_amount
FROM sales
GROUP BY month, category WITH ROLLUP;

在这个结果里，month 有值、category 为 NULL 的行表示当月所有类目合计；month 为 NULL、category 为 NULL 的行表示整体总计。前端拿到这个结果，直接循环渲染并判断最后一列是否为 NULL 即可。

4.2 对汇总行做语义化标记：完整 SQL 写法

为了不对前端隐藏聚合逻辑，实际开发中我更推荐把汇总行的 NULL 直接替换成中文标签，SQL 写成这样：

sql复制SELECT
    COALESCE(DATE_FORMAT(sale_date, '%Y-%m'), '全部月份') AS month,
    COALESCE(category, '全部类目') AS category,
    CASE
        WHEN GROUPING(category) = 1 AND GROUPING(DATE_FORMAT(sale_date, '%Y-%m')) = 0 THEN '月度小计'
        WHEN GROUPING(category) = 1 AND GROUPING(DATE_FORMAT(sale_date, '%Y-%m')) = 1 THEN '总计'
        ELSE '明细'
    END AS row_type,
    SUM(amount) AS total_amount
FROM sales
GROUP BY DATE_FORMAT(sale_date, '%Y-%m'), category WITH ROLLUP;

注意：这里 GROUP BY 和 SELECT 中要尽量使用同样的表达式，避免 MySQL 对表达式的匹配出现意外。执行之后，month、category 里的 NULL 已经被替换成了可读的中文标签，row_type 明确标注了这一行的性质。运营看到这张表，不需要任何额外解释就知道哪些行是合计。

这个方法我用了很多次，要点在于 GROUPING() 函数配合 CASE WHEN 的层级判断。记住 GROUPING() 返回的是位掩码中的对应位，也可以把多个 GROUPING() 相加后统一判断，比如 GROUPING(month) + GROUPING(category) 为 2 时就是总计行，但可读性不如 CASE WHEN 清晰。

4.3 区域+类目+时间的三维汇总：一条 SQL 输出多级报表

再复杂一点，如果运营需要看到"区域、类目、月份"三个维度，同时希望有区域小计、区域+类目小计，以及总计，ROLLUP 依然可以一站解决：

sql复制SELECT
    region,
    category,
    DATE_FORMAT(sale_date, '%Y-%m') AS month,
    SUM(amount) AS total_amount
FROM sales
GROUP BY region, category, DATE_FORMAT(sale_date, '%Y-%m') WITH ROLLUP;

这个结果会逐级上卷，依次生成：

• region + category + month 的明细分组
• region + category 的小计（month 为 NULL）
• region 的合计（category 和 month 为 NULL）
• 全局总计（三个字段均为 NULL）

这就是我在 2.3 里说的递推规则，三维场景直接套用即可。需要注意结果集行数会明显增加，对于一个月数据量上百万的表，这种写法虽然省了代码，但数据接收方要能接受多出来的那些 NULL 占位行。

5. ROLLUP 与 GROUPING SETS、CUBE：MySQL 的聚合扩展家族

MySQL 的 GROUP BY 扩展其实有三兄弟：ROLLUP、GROUPING SETS 和 CUBE。很多人只听说过 ROLLUP，却不知道后两者的存在。

先看 GROUPING SETS。它允许在一条 SQL 里显式指定多个分组维度，如下面写法同时输出按区域、按类目两种分组统计：

sql复制SELECT region, category, SUM(amount) AS total_amount
FROM sales
GROUP BY GROUPING SETS ((region), (category), ());

() 表示无分组的全局总计。GROUPING SETS 相当灵活，可以只计算你关心的那几层，不会像 ROLLUP 那样无差别生成所有层级。

CUBE 则是全维度组合，对所有分组列的所有可能组合都做汇总。可惜的是 MySQL 至今没有完整实现 CUBE 语法，MySQL 8.0 也不能直接用 GROUP BY CUBE(...)。如果确实需要多维度全组合统计，在实际项目中一般用 GROUPING SETS 显式枚举所有组合，或者干脆用多条 SQL 汇总后在应用层合并。

对比起来：当你想让每一层都有汇总行、层级关系固定且明确时，用 ROLLUP 最省事；当只需要特定若干层级时，用 GROUPING SETS 更精准；CUBE 只能停留在概念层面，官方支持的数据库是 PostgreSQL、SQL Server、Oracle 家族。

6. 踩坑记录：ROLLUP 使用中常见的几个问题

6.1 ORDER BY 排序与 ROLLUP 结果的冲突

ROLLUP 的结果中汇总行是紧跟分组插入的，如果你在 SQL 里加了 ORDER BY，很可能导致汇总行的顺序被打乱。尤其是使用 ORDER BY total_amount DESC 这种排序时，汇总行可能会跑到最上面或者夹在中间，看起来非常奇怪。

MySQL 官方文档明确说过：ROLLUP 与 ORDER BY 同时使用时，ORDER BY 会覆盖 ROLLUP 默认的层级顺序。如果你既想要汇总行置底，又想要分组排序，常见的做法是先按业务需要的列排序，保留 ROLLUP 默认层级顺序，不在外层加 ORDER BY；或者把 ROLLUP 结果作为子查询，在外层按 row_type 排序，让汇总行为最后展示。

6.2 LIMIT 对汇总行的影响

直接写 LIMIT 5 会把 ROLLUP 生成的总计行截掉，因为你并不知道汇总行在结果集的第几行。特别是数据量大的时候，汇总行往往排在最后，LIMIT 一限制就丢失了。如果非要 LIMIT，建议先把 ROLLUP 结果包一层子查询再做条件过滤和分页。

6.3 HAVING 条件与汇总行的取舍

HAVING 的作用是对分组结果进行过滤。在 ROLLUP 查询里，HAVING 会把不符合条件的行全部过滤掉，包括汇总行。比如 HAVING total_amount > 10000 就可能导致总计行消失。如果你希望总计行不被过滤，最稳妥的方式还是先算完再在子查询里处理，或者使用 UNION ALL 单独拼接总计行。

6.4 重复分组列的无效 ROLLUP

ROLLUP 的分组列如果有重复，比如 GROUP BY region, region WITH ROLLUP，MySQL 会认为你重复分组了，不会多生成一层汇总。这在实际书写中容易让人困惑，建议保持分组列的规范性，不要为了调整显示顺序而重复列。

6.5 与 DISTINCT 的配合问题

在 MySQL 8.0 中，ROLLUP 和 DISTINCT 同时使用是不被允许的，官方会直接报错。我在早期版本中遇到过这个问题，解决方法依然是先写子查询去掉 ROLLUP，再做 DISTINCT 去重，或者调整业务逻辑避免同时使用。

7. 性能优化与索引设计建议

7.1 ROLLUP 一定比多次查询快吗

这是一个很值得讨论的问题。ROLLUP 减少了 SQL 的发送次数，看起来肯定更快，但实际要分情况。如果表数据量不大，ROLLUP 的额外计算开销可以忽略不计。如果表特别大，ROLLUP 会在 MySQL 服务端完成多层聚合，内存和 CPU 开销并不低。

我从实际生产环境得到的结论是：在千万级以下的表上，ROLLUP 优势明显；数据量超过千万，或者分组列特别多导致结果集膨胀明显，建议先压测，对比一下"一条 ROLLUP"和"两条简单 GROUP BY + 应用层合并"的耗时差异，再决定方案。

7.2 合理利用索引加速分组

索引对 ROLLUP 的加速原理和普通 GROUP BY 一样，核心目标是让分组字段有序排列。对于 GROUP BY region, category WITH ROLLUP 这种查询，建立一个 (region, category) 联合索引，可以让 MySQL 直接利用索引的有序性完成分组，避免临时表和 filesort。

时间字段参与分组时，务必在表达式中保持统一写法。比如使用 DATE_FORMAT(sale_date, '%Y-%m') 分组，索引失效几乎是必然的，因为 MySQL 无法用上 sale_date 本身的索引对这个表达式做直接定位。如果月份统计是高频查询，建议额外维护一个冗余的 month 字段，并在该字段上建索引。

7.3 临时表空间规划

ROLLUP 结果集经常比普通 GROUP BY 多出一到多层汇总行，数据量大时，MySQL 可能会把中间结果放到磁盘临时表中。生产环境如果出现 Created_tmp_disk_tables 指标暴涨，可以适当调大 tmp_table_size 和 max_heap_table_size，或者优化分组列顺序，减少中间过程的无序程度。

8. 总结我的实操建议

把 ROLLUP 用熟之后，你会发现在很多报表场景里，它比多条 SQL 拼装省心得多。根据我的实操经验，只要满足以下条件，就可以放心使用 ROLLUP：

• 需要输出"分组明细 + 小计 + 总计"的完整层级，层级关系固定。
• 数据量没有达到千万以上，服务端聚合开销可接受。
• 尽量避免 ORDER BY 和 LIMIT 与 ROLLUP 同时使用，必须用时先包子查询。
• 使用 MySQL 8.0 及以上版本，借助 GROUPING() 函数准确识别汇总行。
• 业务数据中如果存在 NULL 值，务必用 GROUPING() 或 COALESCE 做好标记，避免数据行和汇总行混淆。

最后再分享一个小技巧：如果运营要的报表里除了合计之外，还需要"同期对比"或者"环比增长率"，在 ROLLUP 生成的结果集上做窗口函数会比在应用层循环计算简洁得多。例如把摘要结果放进子查询，再用 LAG() 取上一行金额，就能把增长率一并在 SQL 中算完，前端拿到直接展示即可。这也是 ROLLUP 这类聚合扩展在报表场景中特别有价值的原因之一。