在电商分类、组织架构、评论回复等存在层级关系的业务场景中，数据库表设计需要选择合适的方案来存储父子节点关系，常见的方案有邻接表、路径枚举、嵌套集、闭包表四种，不同方案适配不同的业务需求。
邻接表设计
邻接表是最简单的层级表设计方案，核心思路是在表中增加一个字段存储父节点的ID，根节点的父ID设为NULL或者0。
表结构设计
以组织架构表为例，结构如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 节点ID，主键 |
| name | varchar(50) | 节点名称 |
| parent_id | int | 父节点ID，根节点为0 |
代码示例
查询某个节点的所有子节点，需要通过递归或者多次查询实现：
-- 查询id为1的节点的直接子节点
SELECT id, name FROM org_structure WHERE parent_id = 1;
-- 递归查询id为1的所有子节点（MySQL 8.0+支持）
WITH RECURSIVE sub_nodes AS (
SELECT id, name, parent_id FROM org_structure WHERE id = 1
UNION ALL
SELECT o.id, o.name, o.parent_id FROM org_structure o
INNER JOIN sub_nodes s ON o.parent_id = s.id
)
SELECT id, name FROM sub_nodes;
优缺点分析
- 优点：设计简单，增删节点只需要修改单条记录，理解成本低，适合层级不深或者不需要频繁查询层级关系的场景。
- 缺点：查询所有子节点、所有父节点需要递归操作，层级很深时查询性能较差，统计层级深度也需要额外计算。
路径枚举设计
路径枚举的核心思路是在表中增加一个字段，存储从根节点到当前节点的完整路径，通常用分隔符拼接节点ID。
表结构设计
同样以组织架构表为例，结构如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 节点ID，主键 |
| name | varchar(50) | 节点名称 |
| path | varchar(255) | 节点路径，如1/2/3，根节点为1 |
代码示例
查询某个节点的所有子节点可以直接通过路径前缀匹配实现：
-- 查询id为1的节点的所有子节点，假设路径分隔符为/
SELECT id, name FROM org_structure WHERE path LIKE '1/%';
-- 查询id为3的节点的所有父节点，先获取path为1/2/3，再拆分路径
SELECT id, name FROM org_structure
WHERE FIND_IN_SET(id, REPLACE('1/2/3', '/', ',')) > 0;
优缺点分析
- 优点：查询子节点、父节点不需要递归，通过字符串匹配就能快速实现，查询层级深度也很方便，直接统计路径分隔符数量即可。
- 缺点：路径长度有限制，如果层级很深可能导致path字段长度不足；增删中间节点时，所有子节点的路径都需要更新，维护成本较高；路径格式需要统一，避免分隔符冲突。
嵌套集设计
嵌套集的核心思路是为每个节点分配两个数值，left和right，满足父节点的left小于所有子节点的left，父节点的right大于所有子节点的right，所有子节点的left和right都在父节点的left和right区间内。
表结构设计
组织架构表结构如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 节点ID，主键 |
| name | varchar(50) | 节点名称 |
| lft | int | 左值 |
| rgt | int | 右值 |
代码示例
查询某个节点的所有子节点，只需要匹配left和right在父节点的区间内即可：
-- 查询id为1的节点的所有子节点，先获取父节点的lft和rgt SELECT child.id, child.name FROM org_structure parent INNER JOIN org_structure child ON child.lft > parent.lft AND child.rgt < parent.rgt WHERE parent.id = 1;
优缺点分析
- 优点：查询某个节点的所有子节点、所有父节点、子树范围都不需要递归，性能很好，适合需要频繁做范围查询的场景。
- 缺点：增删节点时需要重新计算大量节点的left和right值，维护成本极高；无法直接获取节点的父节点，需要额外查询；层级深度也需要额外计算。
闭包表设计
闭包表的核心思路是单独创建一张关系表，存储所有节点之间的祖先-后代关系，包括节点自身的关系（祖先和后代是同一个节点）。
表结构设计
需要两张表，一张是节点表，一张是关系表：
| 表名 | 字段名 | 类型 | 说明 |
|---|---|---|---|
| org_node | id | int | 节点ID，主键 |
| name | varchar(50) | 节点名称 | |
| org_relation | ancestor_id | int | 祖先节点ID |
| descendant_id | int | 后代节点ID | |
| depth | int | 层级深度，0表示同一个节点 |
代码示例
查询某个节点的所有子节点，只需要匹配祖先ID即可：
-- 查询id为1的节点的所有子节点（不包含自身） SELECT n.id, n.name FROM org_relation r INNER JOIN org_node n ON r.descendant_id = n.id WHERE r.ancestor_id = 1 AND r.depth > 0; -- 查询id为3的节点的直接父节点 SELECT n.id, n.name FROM org_relation r INNER JOIN org_node n ON r.ancestor_id = n.id WHERE r.descendant_id = 3 AND r.depth = 1;
优缺点分析
- 优点：查询任意节点的子节点、父节点、层级深度都非常快，不需要递归；增删节点的维护逻辑相对简单，只需要在关系表中插入或删除对应记录即可。
- 缺点：需要额外维护一张关系表，存储成本比其他方案高，尤其是层级很多、节点很多的时候，关系表的数据量会快速增长。
四种方案的选择建议
实际开发中可以根据业务场景选择合适的方案：
- 如果业务层级很浅，不需要频繁查询层级关系，优先选邻接表，实现最简单。
- 如果层级不深，但需要频繁查询某个节点的所有子节点，且增删操作不频繁，可以选择路径枚举。
- 如果层级固定，增删操作极少，需要频繁做子树范围查询，可以选择嵌套集。
- 如果层级深，节点多，增删和查询操作都很频繁，对查询性能要求高，优先选闭包表。
邻接表路径枚举嵌套集闭包表database_table_design修改时间：2026-06-12 02:45:41