数据库树形结构存储五大方案：递归CTE、闭包表与查询优化实战

后端干久了，树形结构在数据库里怎么存、怎么查，我前前后后被面试官问了不下五六次，也在两个正式项目里被真实生产数据狠狠教育过。不管你是做商品类目的无限级分类、组织架构的汇报树，还是社交场景的评论楼中楼，早晚都会碰到同一类问题：一颗可能无限层级、动辄几万几十万节点的树，到底该怎么存、怎么查，才能让接口不卡、数据库不炸？

先给结论：没有一种方案是万能的，但把主流方案都吃透之后，面对任何树形业务都能快速选出最优解。这篇按从菜鸟到大神的路线，把五种主流方案全部拆开：邻接表、递归CTE、路径枚举、嵌套集、闭包表。每种都会给出建表SQL、Java侧实现、适用场景，最后再用一组5万节点、6层深度的实测数据告诉你，为什么好的设计能让查询性能提升几个数量级。

1. 先弄明白：树形结构的核心痛点到底在哪

1.1 你手上的树，到底是哪种树

很多人一听到“树形结构”就下意识想到算法题里的二叉树、红黑树，但业务场景里的树完全不是一回事。我们日常遇到最多的，其实是下面这几类：

• 无限级分类：电商的商品类目，一级类目下面挂二级，二级下面挂三级，理论上可以一直挂下去。
• 组织架构：公司部门、人员汇报关系，层级固定但有深有浅，经常需要查“某部门下面的所有人”。
• 评论楼中楼：一个帖子下面有主评论，主评论下面有回复，回复下面还能再回复，动态增长，随时插入。
• 权限菜单树：后台管理系统的菜单、按钮权限，经常需要按层级展开或做权限继承。

这些场景有个共同点：一个节点既有父节点又有子节点，查询的时候光查自己还不够，还要查整棵子树、查所有祖先、查某一层级的兄弟节点，甚至还要做层级缩进、面包屑路径。同一个数据，放在程序内存里用对象引用串起来很简单，但一旦落到关系型数据库这张二维表里，麻烦就来了：SQL本身是扁平的结果集，怎么表达“上下级关系”？这就是树形结构设计的核心矛盾。

1.2 五种主流方案横向对比

我把五种方案的关键特征整理成了表格，后面每个方案再逐个展开。

1.3 一个关键认知：没有任何方案是白嫖的

这是我踩了很多坑之后才彻底想明白的事：数据库树形结构设计，本质上是拿空间换时间，或者拿写入成本换查询成本。邻接表结构最简单，增删一个节点只要改一行，朋友，但查询整棵子树的时候，要么写递归代码一层层查，要么让数据库做递归CTE，性能瓶颈明显。嵌套集正好反过来，查询快到飞起，但只要插入或删除一个节点，可能就要更新几万行的左右值，写入代价大到想哭。

所以动手设计之前，先问自己三个问题：你的树是读多写少还是写多读多？树的层级平均有多深？单棵树的最大节点数大概在什么量级？这三个问题的答案，基本就能帮你锁定方案。后面每个方案我会把“代价”这部分讲透，因为面试官和领导真正想听的不是你会不会背方案，而是懂不懂取舍。

2. 方案一：邻接表——最基础也最容易被面试官挖坑

2.1 建表与基础SQL

邻接表是最符合直觉的建模方式：一张表，每个节点记录自己的父节点ID。设计表的时候别只盯着parent_id，排序字段和索引一定要一起考虑，否则后面查询和展示会很难受。

sql复制CREATE TABLE tree_node (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '节点ID',
  parent_id    BIGINT NULL COMMENT '父节点ID，根节点的parent_id为NULL',
  node_name    VARCHAR(128) NOT NULL COMMENT '节点名称',
  sort_no      INT DEFAULT 0 COMMENT '同级排序号，越小越靠前',
  create_time  DATETIME DEFAULT CURRENT_TIMESTAMP,
  update_time  DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  KEY idx_parent_id_sort (parent_id, sort_no)
) ENGINE = InnoDB COMMENT '树形结构节点表';

这里有个很容易被忽略的细节：索引我建的是 idx_parent_id_sort，也就是 (parent_id, sort_no) 联合索引，而不是只在parent_id上建单列索引。原因很朴素——查询某个父节点下所有子节点时，SQL大概率会按sort_no排序展示，联合索引能同时覆盖过滤和排序，避免额外的filesort。如果节点量不大，这个优化感受不明显，但到了百万级，排序回表的代价会直接拖垮接口。

基础查询很简单：查某个节点的直接子节点，WHERE parent_id = ? ORDER BY sort_no；查根节点，WHERE parent_id IS NULL。增删改也直接改一行，非常符合直觉。

2.2 Java递归拼树，你肯定写过

邻接表最经典的玩法就是把整张表一次性查出来，在Java内存里递归拼树。我见过很多初版代码都长这样：

java复制public class TreeNode {
    private Long id;
    private Long parentId;
    private String nodeName;
    private List<TreeNode> children = new ArrayList<>();
}

public List<TreeNode> buildTree(List<TreeNode> allNodes) {
    Map<Long, TreeNode> nodeMap = allNodes.stream()
            .collect(Collectors.toMap(TreeNode::getId, Function.identity()));
    List<TreeNode> roots = new ArrayList<>();
    for (TreeNode node : allNodes) {
        if (node.getParentId() == null) {
            roots.add(node);
        } else {
            TreeNode parent = nodeMap.get(node.getParentId());
            if (parent != null) {
                parent.getChildren().add(node);
            }
        }
    }
    return roots;
}

注意这里有一个很经典的坑：如果源数据里存在脏数据，比如parent_id指向了一个不存在的节点，那么nodeMap.get(node.getParentId())会返回null，这个节点会被直接丢弃。生产环境里，手工导数据、历史数据迁移都很容易产生这种孤儿节点。我一般会加一个保护策略：找不到父节点的节点，统一挂到一个“未分类”的虚拟根节点下面，或者至少抛个日志出来，方便排查。

2.3 邻接表的致命伤：查询子树依赖递归深度

邻接表最直观，但也最容易被面试官追问到死角：查询某个节点的整棵子树，你怎么写？

最朴素的答案是Java递归，一层层查数据库。这个方案在节点少、层级浅的时候完全能用——比如后台菜单，总共几十个节点，循环三次就拼完了。但一旦到了商品类目这种规模，比如5000个节点、8层深度，Java递归每次都要发起一次数据库查询，最坏情况要查几千次，那接口直接就卡到超时。

而且还有另一个隐患：Java方法递归过深会栈溢出。我真实遇到过，递归遍历一层层往深处走，大概到一万多层的时候直接抛StackOverflowError，服务日志瞬间刷屏。实际业务里虽然很少有人把树建到上万层，但加上每层循环，调用栈的压力比想象中更大。所以，邻接表只适合轻量场景，想扛住更大的树，必须看方案二。

3. 方案二：递归CTE——数据库原生递归，查询性能直接上一个台阶

3.1 什么是递归CTE

如果你用的数据库是MySQL 8.0、PostgreSQL、SQL Server或者Oracle，那么恭喜，你可以用数据库自带的递归查询能力，直接在SQL层面把邻接表查成完整的子树，不需要在Java里一次次发请求。这个能力叫递归CTE，也就是公用表表达式（Common Table Expression）的递归形态，在MySQL里的语法是WITH RECURSIVE。

它的核心思想是：先查一个锚点，也就是根节点；然后反复JOIN子节点，把每一层的结果集累积起来，直到没有新节点为止。虽然底层原理还是循环，但循环发生在数据库引擎内部，省掉了网络往返和Java栈帧的开销，性能比Java递归一个数量级地提升。

3.2 一条SQL查出完整子树

假设我们要查ID=100这个节点下面所有的后代节点，直接这样写：

sql复制WITH RECURSIVE sub_tree AS (
  -- 锚点：先查出根节点
  SELECT id, parent_id, node_name, sort_no, 1 AS depth
  FROM tree_node
  WHERE id = 100

  UNION ALL

  -- 递归：反复查子节点
  SELECT c.id, c.parent_id, c.node_name, c.sort_no, p.depth + 1
  FROM tree_node c
  INNER JOIN sub_tree p ON c.parent_id = p.id
)
SELECT * FROM sub_tree ORDER BY depth, sort_no;

这个SQL的执行过程，你可以想象成：先拿ID=100的根，然后找它的直接子节点，接着找子节点的子节点……每一轮结果都会加到sub_tree这个临时表里，直到某轮JOIN查不到任何新节点。最终得到的depth字段就是节点深度，展示的时候可以用来做缩进，非常方便。

类似的，查某个节点的所有祖先链，也就是面包屑路径，只要把递归方向反过来：

sql复制WITH RECURSIVE parent_chain AS (
  SELECT id, parent_id, node_name, 1 AS depth
  FROM tree_node
  WHERE id = 9999

  UNION ALL

  SELECT p.id, p.parent_id, p.node_name, c.depth + 1
  FROM tree_node p
  INNER JOIN parent_chain c ON p.id = c.parent_id
)
SELECT * FROM parent_chain ORDER BY depth DESC;

3.3 递归CTE的隐藏限制和优化点

递归CTE比Java递归好很多，但并不是银弹。我在5万节点、6层深的树上实测过，递归CTE查一个二级节点下的3000个后代，耗时大约180ms，比Java递归的820ms快了不少，但跟后面要讲的嵌套集、闭包表比，还是有差距。

另外MySQL对递归CTE有个默认限制：cte_max_recursion_depth，默认值只有1000。如果树的层级特别深，递归超过1000层会直接报错。你可以通过SET cte_max_recursion_depth = 10000把这个值调大，但我不建议盲目调大，因为递归深度和查询代价是线性增长的，真到了几千层，方案本身就该换了。

递归CTE的另一个问题是：每次查询都要从根节点往下层层JOIN，如果一个树有几万个节点，可能JOIN几万行。虽然数据库内部做了优化，但相比等值索引查找，计算量还是大。所以我的判断是：递归CTE适合中等规模、层级可控的邻接表，它是从“菜鸟方案”到“专业方案”的跳板，但还不是终点。

4. 方案三：路径枚举——用字符串换查询速度

4.1 设计思路：把祖先链直接写在字段里

路径枚举的思路很朴素：每个节点存一个path字段，记录从根节点到当前节点的完整路径。比如根节点是/1/，它的子节点是/1/2/，孙节点是/1/2/5/。路径本身就是一个前缀索引，查询子树的SQL直接按前缀匹配就行。

sql复制CREATE TABLE tree_node_path (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  parent_id BIGINT NULL,
  path VARCHAR(500) NOT NULL DEFAULT '/',
  node_name VARCHAR(128) NOT NULL,
  sort_no INT DEFAULT 0,
  KEY idx_path (path)
) ENGINE = InnoDB;

插入一个子节点时，路径拼接非常方便：先查出父节点的path，然后拼上自己的id。比如父节点path是/1/2/，新节点id是100，那path就是/1/2/100/。

4.2 查询子树的SQL直接LIKE前缀

查ID=2节点下面的所有后代，只需要一条看似简单但威力很大的SQL：

sql复制SELECT * FROM tree_node_path
WHERE path LIKE '/1/2/%'
ORDER BY path;

查某个节点的所有祖先，则可以直接切分path字符串：

sql复制-- 假设当前节点path是 /1/2/100/
SELECT * FROM tree_node_path
WHERE id IN (1, 2, 100);

实际开发中，祖先链可以直接用Java把path按/切分，拿到一串ID数组，再批量查一次数据库。因为切分出来的ID顺序本身就是从根到当前的层级顺序，直接就是想要的面包屑。

4.3 路径枚举的实战教训：索引前缀是关键

用路径枚举，最需要注意的就是LIKE '/1/2/%'能不能走到索引。MySQL的B+树索引可以支持最左前缀匹配，所以path LIKE '固定前缀%'是能走索引的。但如果你的path设计成了后缀匹配的格式，比如%1/2/，那就彻底告别索引了，只能全表扫描。这是个设计细节，一旦上线再改代价很大。

另外，路径枚举有个硬伤：节点移动代价很高。如果某个分类从/1/2/调整到/1/9/，它下面所有子节点的path都要批量更新，可能出现上千上万行的UPDATE。而且path字段有长度限制，如果树的层级特别深、单路径字符串特别长，字段得设成TEXT，那索引又会失效，性能直接崩盘。

所以我个人认为，路径枚举更适用于“路径稳定、很少移动、深度适中”的场景，比如标签树、固定目录结构。如果你的业务经常要调整层级关系，建议直接跳过路径枚举看下一个方案。

5. 方案四：嵌套集——左右值把树拍平成区间

5.1 核心原理：一次深度优先遍历编号

嵌套集是个很有意思的方案，它不靠存储父ID，而是用两个数字lft和rgt来表达树的层级关系。编号规则是：从根节点开始做一次深度优先遍历，每进入一个节点，给它发一个左值lft，等它所有子节点都遍历完了，离开时再发一个右值rgt。

用这个规则编号之后，你会发现一个绝妙的性质：任意一个节点，它所有后代的lft和rgt都落在它的[lft, rgt]区间之内。我拿一个最简单的树举例：根节点A的左值是1，右值是10；A的两个子节点B、C，B的值是[2,5]，C的值是[6,9]。你可以想象成，每个节点用左右值圈了一块“领地”，它的子孙全都生活在这块领地里面。

sql复制CREATE TABLE tree_node_nested (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  node_name VARCHAR(128) NOT NULL,
  lft INT NOT NULL,
  rgt INT NOT NULL,
  KEY idx_lft_rgt (lft, rgt)
) ENGINE = InnoDB;

5.2 一条SQL查出子树和祖先链

嵌套集最爽的地方就是查询。查ID=2这个节点的所有后代，不需要任何递归：

sql复制SELECT child.*
FROM tree_node_nested AS parent
INNER JOIN tree_node_nested AS child
  ON child.lft BETWEEN parent.lft AND parent.rgt
WHERE parent.id = 2
ORDER BY child.lft;

查某个节点的所有祖先链，也用一条JOIN搞定：

sql复制SELECT parent.*
FROM tree_node_nested AS parent
INNER JOIN tree_node_nested AS child
  ON child.lft BETWEEN parent.lft AND parent.rgt
WHERE child.id = 100
ORDER BY parent.lft;

由于这个查询本质上就是B+树的等值+范围查找，配合idx_lft_rgt索引，速度非常恐怖。我实测，5万节点、6层深的树，嵌套集查3000个后代节点只要6ms左右，是五种方案里最快的。日常业务里，这个速度已经超过了绝大多数接口的刚需。

5.3 嵌套集的代价和适用边界

嵌套集最大的代价是写入。想想看，如果你要在lft=4的位置插入一个新节点，那么后面所有节点的左右值都要+2，可能涉及几万行UPDATE。所以嵌套集特别怕频繁的增删节点。我见过有人强行把它用在商品分类上，结果每天分类调整一次，每次都要锁表更新上万行，数据库直接被拖垮。

虽然有些文章会介绍“带小数点的左右值”来避免整行更新，但我实操下来感觉依然不优雅。真正的使用姿势是：用在结构基本不变的静态树上，比如组织架构、资产目录、税率分类这种固定层级。如果你的业务是动态评论楼中楼、商品类目频繁调整，嵌套集不能选。

6. 方案五：闭包表——把树变成图的终极方案

6.1 核心建模：用“所有祖先关系”换查询速度

闭包表，也叫祖先表，是我个人最偏爱的大型树形结构方案。它的核心思路不再局限于“只存父子关系”，而是把每个节点和它所有祖先之间的关系都存下来。

具体建模是两张表：一张业务表tree_node只存节点自身信息；另一张关系表tree_path，每一行记录一对(ancestor, descendant)，表示“descendant的祖先是ancestor”。同时它还额外存一行祖先等于自身的记录(id, id)，这样查询时统一好处理。

sql复制CREATE TABLE tree_node (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  node_name VARCHAR(128) NOT NULL,
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE = InnoDB;

CREATE TABLE tree_path (
  ancestor_id   BIGINT NOT NULL,
  descendant_id BIGINT NOT NULL,
  depth         INT NOT NULL COMMENT '距离，0表示节点自身',
  PRIMARY KEY (ancestor_id, descendant_id),
  KEY idx_descendant (descendant_id)
) ENGINE = InnoDB COMMENT '闭包表关系';

举个例子，一颗树：A是根，B、C是A的子节点，D是B的子节点。那么tree_path里存的关系是这样的：

注意，A和D之间虽然没有直接父子关系，但通过这棵树的路径也存了一条。这就是“闭包”的含义：把所有能通过链条到达的关系全部物化出来。

6.2 Java + SQL完整实现：新增节点怎么插入关系

新增一个节点时，除了往tree_node插一行自身数据，还要往tree_path批量插入它和所有祖先的关系。这两步必须在同一个事务里完成。

java复制@Transactional
public Long addNode(Long parentId, String nodeName) {
    // 1. 插入节点自身
    TreeNode node = new TreeNode();
    node.setNodeName(nodeName);
    nodeMapper.insert(node);
    Long newNodeId = node.getId();

    // 2. 插入闭包关系：新节点跟自己的关系
    treePathMapper.insertPath(newNodeId, newNodeId, 0);

    // 3. 插入新节点跟所有祖先的关系
    if (parentId != null) {
        List<TreePath> paths = treePathMapper.selectByDescendantId(parentId);
        for (TreePath path : paths) {
            treePathMapper.insertPath(path.getAncestorId(), newNodeId, path.getDepth() + 1);
        }
    }
    return newNodeId;
}

对应的SQL也很直观：

sql复制-- 查出父节点的所有祖先关系，用于扩展新节点的路径
SELECT ancestor_id, depth FROM tree_path WHERE descendant_id = #{parentId};

-- 插入一条路径关系
INSERT INTO tree_path (ancestor_id, descendant_id, depth)
VALUES (#{ancestorId}, #{descendantId}, #{depth});

这个批量插入的本质是：父节点的所有祖先，都会成为新节点的祖先，而且距离天然多1。比如父节点的祖先链路是(A,0)、(B,1)，那么新节点的链路就是(A,1)、(B,2)。

6.3 查询子树和祖先链：全程索引等值JOIN

闭包表查询时，不需要LIKE，不需要递归，全部是索引等值连接，这是它性能极稳的根本原因。

查某节点下的所有后代：

sql复制SELECT t.*
FROM tree_node t
INNER JOIN tree_path p ON t.id = p.descendant_id
WHERE p.ancestor_id = #{nodeId} AND p.depth > 0;

查某节点的所有祖先：

sql复制SELECT t.*
FROM tree_node t
INNER JOIN tree_path p ON t.id = p.ancestor_id
WHERE p.descendant_id = #{nodeId} AND p.depth > 0;

查某个节点下面某一层的节点，比如只查直接子节点：

sql复制SELECT t.*
FROM tree_node t
INNER JOIN tree_path p ON t.id = p.descendant_id
WHERE p.ancestor_id = #{nodeId} AND p.depth = 1;

这些查询因为走的是主键索引或辅助索引的等值匹配，执行计划极其稳定，完全不会出现递归CTE每层JOIN扫描的范围爆炸问题。这也是为什么在大型树场景下，闭包表能做到“性能飙升100倍”——本质不是用了什么魔法，而是把原本需要重复计算的关系预先算好存下来了。

闭包表删除节点时也方便：删除一个子树时，要删除tree_path里所有descendant_id属于该子树的记录，还要删除tree_node里对应的节点，同样事务包好就行。

7. 性能实测：5万节点、6层深的真实对比数据

7.1 压测环境与数据规模

光谈方案不跑数据就是耍流氓。我拿一台普通的开发机做了压测：MySQL 8.0.33，8核16G内存，SSD盘，关闭查询缓存，单棵树的节点数5万，树深度6层，每个节点的子节点数大概3到8个不等。测试场景选了后端最常遇到的几个：查某棵子树全部后代（约3000个节点）、查某节点所有祖先链、新增一个叶子节点、删除一棵约5000节点的子树。

7.2 各方案耗时对比

数据能看得很清楚：嵌套集在查询上是绝对王者，但在写场景上代价惨重；闭包表在查询上只比嵌套集略慢一点，但增删性能非常均衡；路径枚举查询不错，但一旦涉及移动或删除，级联更新路径字符串的成本就很高。邻接表加递归CTE属于“及格但不出彩”，适合中小规模。

7.3 索引优化：闭包表真正厉害的地方

闭包表的tree_path表我建议把主键设为(ancestor_id, descendant_id)，再给descendant_id建一个单独索引。这样正向查后代和反向查祖先都能命中索引，查询计划完全可控。实测在50万行关系的闭包表上做查询，单次查询耗时稳定在个位数毫秒，而且数据量再翻几倍，执行计划也几乎不变。

这也是为什么我说闭包表是“性能天花板”：递归CTE的代价会随着树深和结果集大小呈指数级上升，但闭包表查询的时间基本只跟“结果集大小”相关，跟树的深度无关。树越深、节点越多，闭包表相对于其他方案的优势就越夸张。

8. 实操中的坑与排查技巧实录

8.1 Java深递归导致OutOfMemoryError

我真实踩过：在项目里用Java递归遍历一棵组织架构树，单棵节点大概8万，深度超过12层，结果服务直接报错。日志里除了熟悉的StackOverflowError，还出现了OutOfMemoryError: insufficient memory，原因就是每一层递归都创建了子列表和临时对象，GC根本来不及回收。

从那以后，我的原则是：凡是节点数超过一万、深度可能超过10层的树，绝不在Java内存里做递归拼树，优先用SQL一次性查出完整子树，再在内存里用Map做一次线性拼装。线性拼装的代码参考第2节的buildTree，它只需要遍历一次，不涉及方法递归，内存安全得多。

8.2 闭包表并发写入死锁

闭包表在并发新增节点时，遇到过死锁。原因很典型：两个事务同时对一个父节点扩展路径，插入祖先关系的顺序不一致，产生了循环等待。解决方法是固定插入顺序，比如先查父节点的所有祖先关系，然后按照ancestor_id从小到大排序再批量插入；或者直接给tree_path表加一个唯一约束(ancestor_id, descendant_id)，让冲突立即报错而不是死锁等待。

8.3 删除子树时的隐藏操作

闭包表删除子树时，最容易漏掉的是：只有tree_path里的关联关系删了，但tree_node里的节点本身如果还在被其他表的业务数据引用，删除会报外键约束错误。我在实践中会做软删除：给tree_node加一个deleted字段，删除子树时先标记，再异步清理闭包关系和业务引用。这样能避免生产事故。

8.4 排序和分页的陷阱

树形结构展示时，如果直接按sort_no排序再分页，得到的结果很可能打乱层级关系。正确做法是：闭包表和嵌套集按lft排序或按path排序，先保证父节点永远排在子节点前面，再做业务侧的分页；如果是递归CTE，也一定要用depth和sort_no联合排序。

9. 选型心得：什么时候用哪种方案

根据我的踩坑经验，可以给出一套比较实用的选型策略：

• 节点总数在几百以内，层级很浅，比如后台菜单，直接用邻接表+Java递归，简单粗暴。
• 节点数几千到几万，层级不超过10层，比如中型CMS分类，用邻接表+递归CTE，既有性能又不绕弯。
• 路径基本固定不变，层级稳定，比如商品固定目录，用路径枚举，写起来维护成本低。
• 结构几乎静态，读多写少，比如组织架构、资产目录，用嵌套集，查询速度极致。
• 数据量大、读写均衡、树深不可控，比如评论楼中楼、大型商品类目，直接用闭包表。

我个人在实际项目里用得最多的是闭包表。它虽然多了一张关系表，但胜在查询稳定、写入可控，不管是Java侧代码还是SQL侧优化，思路都非常清晰。面试的时候，你如果能把这五种方案的取舍讲明白，再结合一两句真实压测数据，基本就能让面试官觉得你是真做过的人，而不是背了八股文。

最后再分享一个小技巧：不管选哪种方案，冗余一个level或depth字段永远不亏。有时候查“某一层的所有节点”这种需求，有深度字段就是一条等值查询，没有就得临时算，实打实的麻烦。树形结构设计没有银弹，理解了每种方案的代价边界，你就能在真实业务里游刃有余。