GROUP BY ... WITH ROLLUP 中小计行字段为 NULL 是 MySQL 用 NULL 标记汇总层级的机制，并非数据丢失；需用 GROUPING() 函数区分真实 NULL 与汇总占位符，且 GROUPING() 仅适用于 MySQL 8.0+。
GROUP BY ... WITH ROLLUP 为什么小计行全是 NULL？
不是数据丢了，是 MySQL 默认用 NULL 标记汇总层级——小计行里被“折叠”的字段（比如 region）会变成 NULL，但你真正需要的是区分“真实 NULL”和“汇总占位符”。
- 必须搭配
GROUPING()函数判断：当GROUPING(region) = 1，说明这行是 region 小计，不是 region 值真为 NULL -
WITH ROLLUP的顺序严格依赖GROUP BY字段顺序：写成GROUP BY region, product WITH ROLLUP，才会先出各 region 下 product 小计，再出 region 小计，最后是总计 - MySQL 8.0+ 支持
GROUPING()，5.7 及更早版本只能靠IS NULL+ 业务逻辑硬判，极易误标
GROUPING() 和 GROUPING_ID() 怎么选？
GROUPING() 看单个字段是否参与汇总，GROUPING_ID() 返回一个整数，二进制位对应每个 GROUP BY 字段的汇总状态，适合多级嵌套判断。
- 例如
GROUP BY a, b, c WITH ROLLUP，某行GROUPING_ID() = 3（二进制011），表示 a 是真实值，b 和 c 是汇总占位 - 别直接用
GROUPING_ID() = 0判“明细行”——它只代表“无任何字段被汇总”，但若原始数据里 a/b/c 本身就有NULL，仍需结合GROUPING()单独验证 - PostgreSQL 不支持这两个函数，得用
GROUPING SETS替代，语法和语义完全不同
WITH ROLLUP 导致排序错乱怎么办？
ROLLUP 行插入位置由引擎内部决定，不保证和 ORDER BY 兼容——尤其在有 LIMIT 或分页时，小计/总计可能被截断或错位。
- 必须显式用
ORDER BY控制汇总行位置：常见做法是加辅助列，如IF(GROUPING(region), 1, 0) AS is_subtotal，再按此列 + 业务字段排序 - 避免在 ROLLUP 查询里用
SELECT *：字段顺序影响GROUPING_ID()的位序，也影响后续排序可维护性 - 如果前端要固定“总计在最底”，别依赖 ROLLUP 自动排序，老实用
UNION ALL拆成明细、小计、总计三部分再合并，可控性高得多
GROUPING() 在 WHERE 或 HAVING 里能用吗？
不能直接用在 WHERE，因为 GROUPING() 是聚合后计算的；但可在 HAVING 或外层查询中过滤汇总行。
- 错误写法：
WHERE GROUPING(region) = 0→ 报错 “Invalid use of group function” - 正确做法一（HAVING）：
HAVING GROUPING(region) = 0→ 过滤掉 region 小计，只留明细和更高层汇总 - 正确做法二（子查询）：
SELECT * FROM (SELECT ..., GROUPING(region) AS g_r FROM t GROUP BY region, product WITH ROLLUP) t2 WHERE t2.g_r = 0 - 注意：HAVING 对性能敏感，尤其大表汇总时，优先考虑在应用层筛，而非强压给数据库
GROUPING 的核心就一点：它不是空值检测工具，而是汇总层级的开关信号。很多人卡在第一步——没意识到 NULL 在 ROLLUP 里是“语法符号”，不是“数据缺失”，后面所有排序、过滤、展示逻辑都会偏移。
