嵌套查询更适合多级分类对账，因其能按需逐层上溯处理动态深度的树形结构（如电子>手机>iPhone>iPhone 15），而JOIN难以一次性拉取所有上级分类的累计库存；MySQL 8.0+可用WITH RECURSIVE展开全路径，5.7则依赖多层嵌套子查询，但性能随层级增加显著下降。
为什么嵌套查询比 JOIN 更适合多级分类对账
因为多级分类（比如「电子 > 手机 > iPhone > iPhone 15」）通常存在动态深度，分类表里用 parent_id 构建树形结构，而库存表只存最末级 category_id。用 JOIN 很难一次性拉出所有上级分类的累计库存，容易漏掉中间层级；嵌套查询能按需逐层上溯，逻辑更可控。
常见错误是直接在 WHERE 里写 (SELECT parent_id FROM category WHERE id = stock.category_id)——这只能查一级，二级就断了。必须用递归或分层展开。
- MySQL 8.0+ 可用
WITH RECURSIVE构建完整路径，再关联汇总 - MySQL 5.7 或低版本得靠多次嵌套子查询，最多展开 3–4 层（取决于业务最大深度）
- PostgreSQL 推荐用
WITH RECURSIVE+LATERAL，性能更稳
MySQL 8.0+ 实现：用 WITH RECURSIVE 展开全路径
假设分类表 category 有 id、name、parent_id，库存表 inventory 有 category_id、qty。目标是算出每个分类（含所有子类）的总库存。
WITH RECURSIVE category_tree AS ( SELECT id, name, parent_id, id as root_id FROM category WHERE parent_id IS NULL UNION ALL SELECT c.id, c.name, c.parent_id, ct.root_id FROM category c INNER JOIN category_tree ct ON c.parent_id = ct.id ) SELECT ct.name, COALESCE(SUM(i.qty), 0) AS total_qty FROM category_tree ct LEFT JOIN inventory i ON i.category_id = ct.id GROUP BY ct.root_id, ct.name;
注意：root_id 是关键，它把整个子树锚定到根节点，否则 GROUP BY 会按叶子节点分组，失去“向上汇总”意义。
MySQL 5.7 兼容方案：用多层嵌套子查询模拟树遍历
如果不能升级，就得手动展开层级。假定最多 3 级（根 → 一级 → 二级 → 叶子），且叶子节点的 level 字段已存（如 level=3 表示末级）：
- 先查所有叶子节点的库存：
SELECT category_id, SUM(qty) qty FROM inventory GROUP BY category_id - 再用三层嵌套把叶子库存“归集”到各级父类：
(SELECT SUM(qty) FROM inventory i2 WHERE i2.category_id IN (SELECT id FROM category WHERE parent_id = c.id))这种写法要重复三次，分别对应 level=2、1、0 - 性能隐患明显：每层都触发一次子查询，数据量过万时响应变慢，建议加
category(parent_id)和inventory(category_id)复合索引
别硬写四层以上——可读性崩坏，维护成本陡增，不如迁移到支持递归的版本。
对账时最容易忽略的边界情况
嵌套查询本身不报错，但结果不准往往卡在这些地方：
- 分类表里存在
parent_id指向不存在的id（脏数据），WITH RECURSIVE会静默截断，建议先跑SELECT * FROM category c WHERE c.parent_id NOT IN (SELECT id FROM category) AND c.parent_id IS NOT NULL - 库存表里
category_id为空或指向已删除分类，LEFT JOIN后变成NULL分组，导致某些分类“消失”，要用COALESCE显式补 0 - 同一商品属于多个分类（比如“折叠屏手机”同时挂“手机”和“平板”），嵌套查询默认按单路径处理，这种场景得先清洗或改用路径字符串（如
/electronics/phone/foldable/）做模糊匹配
多级对账不是纯技术问题，分类体系是否闭环、历史数据是否干净，决定了嵌套查询能不能真正跑通。
