结果总少一层是因为group by仅聚合实际存在的记录，无法自动补全缺失层级；必须先构建完整层级骨架（如distinct组合或递归cte展开），再left join数据并coalesce补零。
用 GROUP BY 处理多级分组时，为什么结果总少了一层？
直接套用 GROUP BY column1, column2 看似能分两级，但实际只是扁平聚合——它不会自动补全缺失层级（比如某地区下没有某个部门，该组合就不会出现在结果里）。真要“带层级结构”，本质是需要构造出完整的层级骨架，再左连接数据。
常见错误现象：GROUP BY region, dept 出来的行数比预期少；想看每个 region 下所有 dept 的汇总，哪怕某些 dept 没有记录，也得显示为 0。
- 先用
SELECT DISTINCT或UNION构建完整层级组合（如所有region× 所有dept） - 再用
LEFT JOIN关联原始数据表，确保骨架不丢行 -
COALESCE(SUM(...), 0)补零，避免NULL
递归查询实现树形层级分组（PostgreSQL / SQL Server）
当层级深度不确定（比如组织架构中部门可能嵌套 5 层），GROUP BY 本身无法动态展开。必须用递归 CTE 构造路径，再按路径聚合。
关键点：递归 CTE 的锚点（anchor）必须选顶层节点（如 parent_id IS NULL），递归部分用 JOIN 连自己，拼接 path 字段用于后续分组。
- PostgreSQL 示例：
WITH RECURSIVE org AS (SELECT id, name, parent_id, ARRAY[id] AS path FROM departments WHERE parent_id IS NULL UNION ALL SELECT d.id, d.name, d.parent_id, o.path || d.id FROM departments d JOIN org o ON d.parent_id = o.id) - 之后用
SELECT array_length(path, 1) AS level, ... GROUP BY path即可按层级深度或完整路径聚合 - SQL Server 用
OPTION (MAXRECURSION n)控制深度，否则默认只跑 100 层
ROLLUP 和 CUBE 能否替代手动构造层级？
能快速生成小范围的多维汇总（比如 GROUP BY region, dept WITH ROLLUP），但它只提供预设的空值占位（NULL 表示“全部”），不是真正的层级结构——没有父子关系、不可排序、不能过滤中间层。
典型误用场景：把 ROLLUP 结果当树形菜单渲染，结果发现 “华东” 下的 “全部部门” 和 “销售部” 并列，无法区分层级归属。
-
ROLLUP(a,b,c)生成 (a,b,c)、(a,b,NULL)、(a,NULL,NULL)、(NULL,NULL,NULL) 四种组合 -
CUBE更暴力，会把所有排列组合都算一遍，数据量大时性能跳崖 - 如果只是报表需要“小计/总计”，
ROLLUP简单有效；但要做前端树形渲染或权限校验，还是得靠递归或预生成路径字段
MySQL 8.0 以前怎么模拟递归分组？
没有原生递归 CTE，硬办法是用自连接 + 限定连接次数（比如最多 4 层就写 4 次 LEFT JOIN），但代码冗长且难维护。更实用的是在应用层或中间表里预计算好层级路径。
例如：给部门表加一个 path 字段（格式 '/1/5/12/'），每次插入/移动时用程序更新。这样查询时只需 WHERE path LIKE '/1/%' 就能拿到整个子树，再配合 GROUP BY 即可。
- 路径字段必须加索引，否则
LIKE '/1/%'会全表扫 - 避免用字符串函数（如
SUBSTRING_INDEX）实时拆解路径做分组，性能极差 - 如果业务允许，升级到 MySQL 8.0+ 直接用
WITH RECURSIVE，省去同步路径的麻烦
层级分组最难的不是语法，而是决定“骨架由谁定义”——是数据本身天然存在（如地理区域编码），还是业务规则强约束（如部门层级必须 3 级）？前者可查表生成，后者往往得靠人工配置或应用层兜底。
