直接 group by 无法正确汇总叶子节点，因为会将所有层级节点（含父类）一并统计，导致父类数据被子节点重复累加而失真；业务只关心无子节点的叶子，需用 not exists 或 left join ... is null 判断节点是否为叶子（即其 category_id 不作为任何记录的 parent_id 出现），再聚合销售数据。
为什么直接 GROUP BY 无法正确汇总叶子节点
多级分类树里，GROUP BY category_id 会把所有层级的节点都算进去，但业务上往往只关心“没有子类”的叶子节点。比如商品类目表里，electronics 是父类，smartphone 和 laptop 是它的子类，而 iphone-15 才是叶子——它下面再没 children。如果直接按 category_id 汇总销售数据，父类数据会被重复累加（因为子节点也归属它），结果就失真。
关键判断逻辑是：一个节点是叶子，当且仅当它在树结构中不作为任何其他节点的 parent_id 出现。
- 用
NOT EXISTS或LEFT JOIN ... IS NULL判断是否为叶子 - 避免用
IS NULL直接查parent_id字段——根节点可能也是NULL，但这不代表它是叶子 - 若树表有
level或path字段，可辅助判断，但不可替代实际子节点存在性检查
用 NOT EXISTS 筛出叶子节点再聚合
这是最通用、兼容性最好的写法，适用于 MySQL 5.7+、PostgreSQL、SQL Server 等主流数据库。
SELECT t.category_id, t.name, SUM(s.amount) AS total_sales FROM categories t INNER JOIN sales s ON t.category_id = s.category_id WHERE NOT EXISTS ( SELECT 1 FROM categories c WHERE c.parent_id = t.category_id ) GROUP BY t.category_id, t.name;
注意点：
-
NOT EXISTS子查询必须关联外层t.category_id，否则变成全表扫描 - 聚合前必须先过滤出叶子，不能把
NOT EXISTS放在HAVING里——HAVING对的是分组后结果，而叶子判定是行级逻辑 - 如果
sales表里存在未映射到categories的category_id，需先INNER JOIN或加WHERE s.category_id IN (SELECT category_id FROM categories)
用 LEFT JOIN + IS NULL 替代 NOT EXISTS（适合调试）
语义更直观，执行计划有时更容易理解，但要注意连接条件写法。
SELECT t.category_id, t.name, SUM(s.amount) AS total_sales FROM categories t INNER JOIN sales s ON t.category_id = s.category_id LEFT JOIN categories c ON c.parent_id = t.category_id WHERE c.category_id IS NULL GROUP BY t.category_id, t.name;
常见错误：
- 写成
WHERE c.parent_id IS NULL—— 错，应判断被左连接的表主键是否为NULL - 漏掉
INNER JOIN sales，导致叶子节点即使无销售记录也被列出（而业务通常只要“有销售的叶子”） - MySQL 8.0+ 中若
categories无索引在parent_id上，该查询会明显变慢
带层级路径的树结构如何优化叶子识别
如果表里存了类似 path = '/1/5/23/' 的字段（如使用闭包表或嵌套集模型），可以跳过子查询，直接用字符串函数判断是否为末级。
例如 PostgreSQL：
SELECT t.category_id, t.name, SUM(s.amount) FROM categories t INNER JOIN sales s ON t.category_id = s.category_id WHERE t.path = (SELECT MAX(c.path) FROM categories c WHERE c.path LIKE t.path || '%') GROUP BY t.category_id, t.name;
但这个写法有陷阱：
-
MAX(path)依赖字典序，若path是/1/10/和/1/2/，MAX会错判/1/10/更大 - 真正安全的做法是统计路径中
/的数量：ARRAY_LENGTH(STRING_TO_ARRAY(TRIM(t.path, '/'), '/'), 1)，再和最大深度比对 - 这种方案只适合已知树深、且路径格式严格统一的场景；不如
NOT EXISTS通用可靠
叶子节点判定本身不复杂，但容易在“以为某字段为空就是叶子”或“把聚合和过滤顺序搞反”上栽跟头。实际写的时候，先单独跑一遍 SELECT * FROM categories WHERE NOT EXISTS (SELECT 1 FROM categories c WHERE c.parent_id = categories.category_id) 确认叶子集合是否符合预期，再加聚合——这步省不得。
