MySql递归查询：如何高效获取树形结构的所有子节点

最新推荐文章于 2026-03-01 11:20:52 发布

原创

最新推荐文章于 2026-03-01 11:20:52 发布 · 870 阅读

标签

#MySql #递归查询 #树形结构 #数据库优化

1. 从一次“坑爹”的需求说起：为什么我们需要递归查询？

我记得几年前刚接手一个后台管理系统重构项目时，遇到了一个让我头疼了好几天的问题。系统里有一个“组织架构”模块，用的是最经典的树形结构数据——部门下面有子部门，子部门下面还有员工组，一层套一层。产品经理跑过来说：“咱们能不能在页面上点一下某个大部门，然后它下面所有的子部门、孙部门，不管嵌套了多少层，都能一次性列出来？顺便把总人数也统计一下。”

我当时第一反应是：“这还不简单？parent_id关联查询嘛！”于是吭哧吭哧写了个方法，用代码循环查询。先查第一层子节点，然后遍历这些子节点，再查它们的子节点……逻辑是没错，但性能简直是一场灾难。当一个部门层级有七八层，子节点好几百个的时候，页面加载慢得像蜗牛，数据库连接数飙升，差点把测试环境搞崩。

那次经历让我彻底明白，用应用程序代码（比如Java、Python）在内存里做递归遍历，对于深层级、大数据量的树形结构来说，是一个非常低效的选择。每一次查询都是一次数据库连接和IO操作，网络延迟和查询开销会被无限放大。真正的解决方案，必须让“递归”这个动作发生在离数据最近的地方——也就是数据库内部。这就是MySql递归查询的价值所在：用一句SQL，搞定整个“家族谱系”的查询，把复杂逻辑和计算压力交给数据库引擎，我们只拿结果。

那么，哪些场景会高频用到这种技术呢？我梳理了一下，其实非常普遍：

组织架构与权限管理：就像我遇到的例子，查询某个分公司下的所有部门和人员。
多级分类系统：电商网站的商品分类（如：家电 -> 大家电 -> 冰箱 -> 对开门冰箱），需要获取某个分类下的所有商品。
评论楼中楼与回复链：展示一条评论下的所有回复，以及回复的回复。
菜单与路由权限树：根据用户角色，动态加载其有权访问的所有层级菜单。
地区联动数据：获取某个省份下的所有市、区县。

如果你也在为类似的问题写一堆循环代码，或者被JOIN到头晕也搞不定不定层级的查询，那么接下来的内容就是为你准备的。我们直接进入实战，看看MySql到底怎么玩转递归。

2. 基础准备：如何设计你的树形数据表？

在施展“递归查询”这个魔法之前，你得先有一个合适的“魔法阵”——也就是数据表结构。设计不好，后续查询会事倍功半。

2.1 两种经典的表结构设计

根据我这些年的经验，存储树形结构，主流就两种设计模式，各有优劣。

第一种，邻接表模型。 这是最简单、最直观，也是你可能已经在用的方式。就是每个节点记录自己的直接上级是谁。

CREATE TABLE `department` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '部门ID',
  `name` varchar(100) NOT NULL COMMENT '部门名称',
  `parent_id` bigint(20) DEFAULT NULL COMMENT '父部门ID，顶级部门为NULL或0',
  PRIMARY KEY (`id`),
  KEY `idx_parent_id` (`parent_id`) -- 非常重要！必须为parent_id建索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='部门表（邻接表模型）';

优点：结构清晰，插入、移动节点（修改parent_id）非常方便。缺点：查询所有子孙节点，或者查询从根到某节点的完整路径，非常困难且低效，通常需要递归。这恰恰是我们今天要攻克的核心难题。

第二种，路径枚举模型。 它在每个节点上额外记录一个字段，存储从根节点到自己的完整路径。

CREATE TABLE `category` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '分类ID',
  `name` varchar(100) NOT NULL COMMENT '分类名称',
  `path` varchar(1000) NOT NULL COMMENT '路径，如 /1/3/7/',
  PRIMARY KEY (`id`),
  KEY `idx_path` (`path`(255)) -- 对路径前缀建立索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分类表（路径枚举模型）';

假设数据是：1(食品)，3(零食)，7(膨化食品)。那么id=7的记录，path字段就是/1/3/7/。

优点：查询某个节点的所有子节点变得极其简单！SELECT * FROM category WHERE path LIKE '/1/%'，一个LIKE查询就能搞定所有后代。查询祖先路径也很快，直接解析path字段即可。缺点：路径长度有限（受字段类型限制），维护成本高。插入新节点、移动节点时，需要更新该节点及其所有子孙节点的path字段，容易出错，写操作性能差。

怎么选？ 我的建议是：如果你的业务以“读”为主，且层级相对固定（比如地区、分类），路径枚举是个“空间换时间”的好选择。如果你的业务频繁增删改节点（比如拖拽调整组织架构），那么邻接表更灵活，配合我们今天要讲的递归查询，也能高效解决“读”的问题。