rollup生成的null是层级标记而非脏数据，代表上层维度汇总；需用grouping()区分真实null，避免误过滤，并严格按group by前缀顺序order by。
ROLLUP 生成的 NULL 值不是脏数据，是层级标记
用 GROUP BY ... WITH ROLLUP 时，结果里突然冒出一堆 NULL，第一反应常是“数据出错了”或“JOIN 搞崩了”。其实那是 MySQL（或兼容该语法的引擎）主动填的占位符，代表当前行统计的是上层维度——比如按 region、city、product 三级 ROLLUP，某行 city 是 NULL、product 是 NULL，就表示这是该 region 下的汇总。
实操建议：
- 别急着
WHERE city IS NOT NULL过滤，先看清楚哪一列变NULL对应哪一级汇总 - 用
COALESCE(city, '(all cities)')或IF(city IS NULL, '(total)', city)把占位符转成可读标签 - 注意：SQL 标准中
ROLLUP是GROUPING SETS的语法糖，MySQL 5.7+ 支持，但旧版只认WITH ROLLUP写法
ORDER BY 必须匹配 GROUP BY 字段顺序，否则 ROLLUP 乱套
ROLLUP 依赖字段排列顺序决定层级关系。如果 GROUP BY region, city, product WITH ROLLUP，那层级就是 region → (region+city) → (region+city+product) → region 总计。但一旦加了 ORDER BY product, city，结果排序打乱，人眼根本分不清哪行是哪级汇总，尤其字段值本身有重复时。
实操建议：
-
ORDER BY只能按GROUP BY列**前缀顺序**写，比如ORDER BY region, city可以，ORDER BY city不行 - 真要按某维度排序（如想让城市名从 A 到 Z），得在外层套一层查询：
SELECT * FROM (SELECT ... GROUP BY region, city WITH ROLLUP) t ORDER BY region, city - PostgreSQL / SQL Server 的
ROLLUP对ORDER BY更敏感，MySQL 稍宽松但行为不一致，统一按前缀顺序最稳
多维 ROLLUP 和 SUM(CASE WHEN ...) 本质不同，别混用
有人看到“要算各城市销售额 + 各城市新客数 + 全局总销售额”，就想在一个 ROLLUP 里塞三个 SUM，再补几个 CASE WHEN 分条件聚合。这会出两个问题：一是 ROLLUP 本身只管分组结构，不干预聚合逻辑；二是 CASE WHEN 在 ROLLUP 行里可能因 NULL 维度导致误判（比如 city IS NULL 时还去匹配城市名）。
实操建议：
- 所有指标用同一套分组逻辑就直接并列写
SUM(sales), COUNT(customer_id), AVG(price) - 如果某些指标需不同过滤条件（如“新客数”只算注册 7 天内用户），必须提前在子查询或 CTE 里算好字段，再进
ROLLUP，而不是在SELECT里现场CASE - MySQL 8.0+ 支持
GROUPING()函数，可用GROUPING(city) = 1明确判断该行是否为 city 级汇总，比靠IS NULL更可靠
ROLLUP 结果集行数爆炸？检查维度基数和 NULL 值分布
三列 GROUP BY a, b, c WITH ROLLUP 理论最多产生 (n_a + 1) × (n_b + 1) × (n_c + 1) 行。如果其中一列（比如 order_id）几乎每行都不同，ROLLUP 就会生成海量“单条订单 + 所有上级汇总”，完全失去统计意义。
实操建议：
- 只对真正有层级关系的离散维度用
ROLLUP：地区、时间周期（年/月/日）、类目树，别把流水号、UUID、明细 ID 往里塞 - 执行前先
SELECT COUNT(DISTINCT a), COUNT(DISTINCT b), COUNT(DISTINCT c)看基数，任一列 > 1000 就要警惕 - 如果必须带高基列，改用
GROUPING SETS ((a,b), (a), ())显式控制汇总组合，避免全排列
ROLLUP 的核心其实是“自动补全分组组合”，它不理解业务语义，只机械展开。最容易被忽略的是：当某维度值本身就是 NULL（比如未填写城市），和 ROLLUP 自动生成的 NULL 完全无法区分——这时必须提前清洗或用 GROUPING() 辅助判断。
