GROUP BY WITH ROLLUP 中的 NULL 行是MySQL自动插入的汇总占位符，非错误或缺失数据；最右列NULL表示该组小计，全NULL为总计，需用GROUPING()函数精准识别层级。
GROUP BY WITH ROLLUP 生成的 NULL 行到底代表什么
它不是错误，也不是数据缺失，而是 MySQL 自动插入的汇总占位符。每一级 NULL 对应一个上卷层级：最右列是小计，再左一列是该组内所有小计的合计，依此类推。比如 GROUP BY region, city WITH ROLLUP 中，(‘East’, NULL) 表示 East 区所有城市的汇总，(NULL, NULL) 才是全表总计。
常见错误是直接用 WHERE city IS NOT NULL 过滤，结果把 (‘East’, NULL) 这类合法小计也干掉了。正确做法是用 GROUPING() 函数（MySQL 8.0.12+）或条件判断字段是否为 NULL 且上一级非空。
- MySQL 8.0.12+ 推荐写法：
SELECT IF(GROUPING(city), 'Total for region', city) AS city_label - 兼容旧版可写：
IF(city IS NULL AND region IS NOT NULL, 'Region subtotal', IF(region IS NULL, 'Grand total', city)) -
WITH ROLLUP必须紧跟在GROUP BY列表后，不能加HAVING或其他修饰
ORDER BY 和 WITH ROLLUP 的顺序冲突怎么解
WITH ROLLUP 会强制按 GROUP BY 列的自然顺序生成汇总行，如果你在 ORDER BY 里混用 ASC/DESC 或非分组字段，结果顺序会不可控，甚至让汇总行插在中间。
真实场景中常想“先按销售额降序排城市，再出区域小计”，但 WITH ROLLUP 不吃这套。它只认 GROUP BY 的声明顺序。
- 必须把排序逻辑前置：先用子查询或 CTE 按需排序，再在外层做
GROUP BY ... WITH ROLLUP - 避免在
ORDER BY中引用未出现在SELECT或GROUP BY中的列 - MySQL 5.7 默认启用
sql_mode=ONLY_FULL_GROUP_BY，会直接报错Expression #1 of ORDER BY clause is not in GROUP BY clause，得先确认模式
和普通 GROUP BY 相比，WITH ROLLUP 的性能代价在哪
它不是简单多加几行结果，而是在执行期构建多层分组树，内存占用和计算量随分组维度数指数增长。3 个字段的 WITH ROLLUP 实际要算 2³ = 8 种组合（含全 NULL），不是 3+1 行。
线上大表慎用，尤其当某字段高基数（如 user_id）被误放进 GROUP BY 列表时，WITH ROLLUP 可能生成百万级汇总行，拖垮整个查询。
- 先用
EXPLAIN FORMAT=JSON看group_by_with_rollup是否为true，并关注rows_examined - 聚合前务必用
WHERE严格过滤数据范围，别指望HAVING来事后裁剪 - 替代方案：用
UNION ALL显式拼接不同粒度的GROUP BY查询，可控性更强、更容易加索引
PostgreSQL 或 SQL Server 用户别硬套 —— 没有原生 WITH ROLLUP
MySQL 的 WITH ROLLUP 是方言，PostgreSQL 要用 GROUPING SETS，SQL Server 同样支持但语法细节不同。直接迁移会报错 Unknown syntax 或返回空结果。
比如同样想按 region, city 小计+总计，PostgreSQL 写法是：GROUP BY GROUPING SETS ((region, city), (region), ())，其中 () 表示全表总计，不是 NULL, NULL。
- 注意
GROUPING()函数行为一致，但 PostgreSQL 返回int（0/1），MySQL 返回bool - SQL Server 支持
WITH ROLLUP，但要求GROUP BY列不能有表达式，比如YEAR(order_date)会失败 - 跨数据库抽象时，别依赖
WITH ROLLUP的隐式 NULL 标记，统一用GROUPING()判断更可靠
ROLLUP 的层级关系容易看花眼，尤其是嵌套了 CASE 或函数的时候，NULL 到底属于哪一层，得对着执行计划里的 grouping_id 一个个对。别光看结果集，先查 GROUPING() 值最稳。
