oracle 19c无“group by auto”语法，“自适应分组聚合”实为三类场景统称：动态分组维度、null值可控处理（用nvl/coalesce）、避免数据倾斜；需结合where预过滤、rollup/cube分层汇总及grouping()识别小计行。
GROUP BY 本身不“自适应”，但你可以控制分组行为
Oracle 19c 没有叫 GROUP BY AUTO 或 ADAPTIVE GROUP 的语法。所谓“自适应分组聚合”，实际是开发者对以下三类场景的统称：分组字段动态变化（如按月/季/年切换）、空值参与分组时行为可控、以及在聚合中避免因数据倾斜导致的执行计划退化。这些都不是靠一个开关就能解决，而是靠明确写法+参数配合。
用 NVL / COALESCE 处理 NULL 分组值，避免意外丢行
当分组字段含 NULL，Oracle 默认把所有 NULL 归为同一组——这看起来像“自动合并”，但容易掩盖业务语义。比如按 region 分组统计销售额，region IS NULL 可能代表“未分配区域”，你不希望它和某个真实区域混在一起。
- 错误写法：
GROUP BY region→ 所有NULL被强行归为一组，且无法区分是缺失还是未知 - 推荐写法：
GROUP BY NVL(region, 'UNASSIGNED')或GROUP BY COALESCE(region, 'UNKNOWN', 'N/A') - 注意：
NVL只支持两个参数，COALESCE支持多参数且符合 SQL 标准，但 Oracle 中性能几乎无差别 - 副作用：加了
NVL后，如果该列上有索引，原索引可能无法用于分组扫描（除非建函数索引）
用 ROLLUP / CUBE 替代硬编码多级分组，减少 SQL 维护成本
当你需要同时输出“按部门”“按部门+岗位”“总计”三层聚合结果时，别写三个 UNION ALL。用 GROUP BY ROLLUP(dept, job) 一条语句就能生成层级汇总，且 Oracle 19c 的优化器对 ROLLUP 有专门的快速排序路径（GROUP BY SORT），比手工拼接快 20%~40%。
-
GROUP BY ROLLUP(a, b)→ 生成 (a,b)、(a,NULL)、(NULL,NULL) 三组 -
GROUP BY CUBE(a, b)→ 还额外包含 (NULL,b)，适合做交叉分析 - 必须搭配
GROUPING()函数识别哪一层是小计行：CASE WHEN GROUPING(dept) = 1 THEN 'TOTAL' ELSE dept END - 陷阱：如果 a 或 b 列本身就有
NULL值，GROUPING()返回 1 仅表示“这是 ROLLUP 生成的占位符”，不是原始数据的NULL—— 别混淆这两者
聚合前加 WHERE 过滤，比 HAVING 更早削减数据量
很多人习惯把所有条件都塞进 HAVING，觉得“反正都是过滤”。但在 Oracle 19c 中，WHERE 在分组前执行，HAVING 在分组后执行。哪怕只是过滤掉 5% 的原始行，也能显著降低内存中哈希分组（HASH GROUP BY）的中间结果大小。
- 低效写法：
SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING AVG(salary) > 5000→ 先算出所有部门平均值，再筛 - 高效写法：
SELECT dept, AVG(salary) FROM emp WHERE salary > 0 GROUP BY dept HAVING AVG(salary) > 5000→ 先剔除异常零薪记录，再分组 - 特别注意：
WHERE不能引用聚合函数，HAVING不能引用非分组字段（除非是常量或GROUPING_ID()等特殊函数） - 验证方式：查执行计划，确认
FILTER操作是否出现在HASH GROUP BY之前
真正影响“自适应”的，不是语法糖，而是你是否清楚每条数据在进入 GROUP BY 前经历了什么过滤、是否被 NVL 重写过、以及分组维度是否真的需要全量展开。Oracle 19c 的优化器很聪明，但它不会替你猜业务含义——写错一个 GROUPING() 条件，报表就可能多出一倍的“总计行”。
