在多级分类树的场景里，直接按 category_id 做 GROUP BY 汇总，结果十有八九是错的——因为所有层级的节点（包括父类）都会被统计进去，导致父类数据被子节点重复累加而失真。业务真正关心的，是那些没有子节点的叶子节点，也就是在树结构里，这个 category_id 不会作为任何其他记录的 parent_id 出现。要实现这个目标，就得用 NOT EXISTS 或 LEFT JOIN ... IS NULL 先判断节点是不是叶子，然后再聚合销售数据。
为什么直接 GROUP BY 无法正确汇总叶子节点
举个简单的例子：商品类目表里，electronics 是父类，smartphone 和 laptop 是它的子类，而 iphone-15 才是真正的叶子——它下面再没有更细的类目了。如果直接按 category_id 汇总销售数据，父类数据会被子节点重复累加，结果自然失真。
关键判断逻辑其实就一句话：一个节点是叶子，当且仅当它在树结构中不作为任何其他节点的 parent_id 存在。这里有几点需要特别留意：
NOT EXISTS或LEFT JOIN ... IS NULL才是判断叶子的正确姿势- 千万别直接用
WHERE parent_id 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放在HA VING里——HA VING处理的是分组后的结果，而叶子判定是行级逻辑 - 如果
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)，确认叶子集合符合预期，再加聚合——这一步省不得。
