WITH ROLLUP 生成的 NULL 是汇总标记而非错误，按 GROUP BY 字段顺序从右到左逐级聚合，需用 GROUPING() 或 IF 判断层级并排序，不可用 WHERE 过滤 NULL，灵活性不足时应改用 UNION ALL 或 GROUPING SETS。

WITH ROLLUP 生成的 NULL 值不是错误，是汇总标记

MySQL 中 WITH ROLLUP 会在分组结果末尾插入额外行，用 NULL 表示该层级的聚合（小计或总计）。这不是数据缺失，而是 SQL 引擎刻意写入的占位符。常见误解是以为查询出错了，或者急着用 IFNULL() 全局替换——这反而会掩盖真实汇总结构。

实际使用时建议：

• 先确认 GROUP BY 字段顺序：越靠前的字段层级越高，ROLLUP 按从右到左逐级收口（例如 GROUP BY a, b, c WITH ROLLUP 会产生 (a,b,c)、(a,b,NULL)、(a,NULL,NULL)、(NULL,NULL,NULL) 四类行）
• 用 CASE WHEN 或 COALESCE() 有选择地美化显示，比如只把最末级的 NULL 替换为 '总计'，中间级保留 NULL 便于程序识别层级
• 避免在 WHERE 中过滤 IS NULL 字段——可能误删合法汇总行

ORDER BY 和 WITH ROLLUP 的执行顺序容易颠倒

WITH ROLLUP 是在分组阶段完成的，而 ORDER BY 发生在结果集生成之后。如果直接写 ORDER BY col，汇总行里的 NULL 会被排到最前面（默认升序），打乱“明细→小计→总计”的阅读逻辑。

更稳妥的做法：

• 用 GROUPING() 函数（MySQL 8.0+）判断某列是否参与了当前行的分组：返回 1 表示该列为 ROLLUP 生成的 NULL，可据此排序，例如 ORDER BY GROUPING(region), region
• 兼容老版本 MySQL（5.7）可用 IF(region IS NULL, 1, 0) 模拟分组标识，再按此排序
• 不要依赖字段值本身的自然顺序来区分明细和汇总——不可靠

ROLLUP 不支持部分字段跳过，也不等价于多次 UNION

WITH ROLLUP 是原子性操作，无法指定“只对 city 小计，不对 region 小计”。如果写 GROUP BY region, city WITH ROLLUP，就一定会产生 region 级小计和全局总计，不能跳过其中一层。

需要灵活控制汇总粒度时：

• 别硬扛，改用 UNION ALL 显式拼接：分别查 GROUP BY region, city、GROUP BY region、GROUP BY ()，再统一排序
• 注意各子查询字段数和类型必须严格一致，否则 UNION 报错；数值字段补 NULL，字符串字段补 '' 都要手动对齐
• WITH ROLLUP 在大数据量下通常比多个 UNION 更快，因为它只扫描一次表；但灵活性差，得按需取舍

其他数据库没有 WITH ROLLUP，但有等价方案

PostgreSQL、SQL Server、Oracle 都不支持 MySQL 风格的 WITH ROLLUP，但提供了标准 SQL 的 GROUPING SETS（SQL:1999 起支持），功能更细、更可控。

例如想同时获得 (region, city)、(region)、() 三组统计，在 PostgreSQL 中写：

SELECT region, city, COUNT(*) 
FROM sales 
GROUP BY GROUPING SETS ((region, city), (region), ())

关键差异点：

• GROUPING SETS 明确列出所有需要的分组组合，不会自动生成中间层
• 同样可用 GROUPING() 函数识别每行属于哪个集合
• MySQL 8.0+ 已支持 GROUPING SETS，但很多线上环境仍是 5.7，所以 WITH ROLLUP 还得会

真正难的不是写出 ROLLUP，而是看懂执行计划里它怎么影响临时表和排序；还有就是业务方突然说“只要省一级小计，不要市一级”，这时候得立刻意识到 ROLLUP 不顶用，得切回 UNION 或应用层聚合。