树形结构是业务系统里最常见的数据形态之一，部门组织架构、商品分类、权限菜单、评论回复，本质上都是一棵树。要在关系型数据库里表达这种层级关系，最主流的做法是给每张表加一个父ID字段，让子节点通过这个字段指向父节点的主键。思路听起来简单，但真正动手插入数据时，不少开发者会遇到父ID怎么确定、批量插入怎么保证顺序、插入完成后怎么验证层级正确等问题。本文从表设计讲起，一步步演示插入树形数据的完整流程。
一、邻接表模型：用父ID字段表达层级
邻接表（Adjacency List）是最直观的树形存储模型：表中每一行代表一个节点，主键是节点ID，另设一个parent_id字段指向父节点的主键，根节点的父ID通常置为NULL或0。以一个部门表为例，建表语句如下：
CREATE TABLE department (
id INT AUTO_INCREMENT PRIMARY KEY,
dept_name VARCHAR(50) NOT NULL COMMENT '部门名称',
parent_id INT DEFAULT NULL COMMENT '父部门ID，根节点为NULL',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_parent FOREIGN KEY (parent_id)
REFERENCES department(id)
ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
这张表里有一个关键细节：parent_id上加了外键约束，指向本表的主键。这个约束的价值在于防止插入时把父ID写成一个根本不存在的节点，从数据库层面杜绝了孤儿节点的产生。如果没有这个约束，应用层一旦漏校验，就会出现某个部门挂在一个已被删除的父节点下面，整棵子树在查询时直接丢失。
自引用外键在MySQL的InnoDB引擎中是被支持的，但要注意parent_id列必须建索引，InnoDB会自动为外键创建索引，所以无需手动添加。如果用的是不支持外键的存储引擎（比如MyISAM），就只能靠应用层或触发器来保证引用完整性了。
二、单个节点的插入：先拿父ID再插入
插入子节点的前提是知道父节点的ID。最常见的写法是先查询父节点，再把查到的ID写进插入语句。例如要在"技术研发部"下面新增一个"后端组"，分两步完成：
-- 第一步：查出父节点的ID
SELECT id FROM department WHERE dept_name = '技术研发部';
-- 假设查到 id = 3，第二步：插入子节点
INSERT INTO department (dept_name, parent_id) VALUES ('后端组', 3);
这种写法在低并发场景下没问题，但如果两个请求同时操作，中间的查询结果可能过期。更稳妥的做法是在插入语句里直接嵌套子查询，让数据库在一次语句内完成"找父节点、写入子节点"的动作：
INSERT INTO department (dept_name, parent_id) SELECT '后端组', id FROM department WHERE dept_name = '技术研发部' LIMIT 1;
这里用SELECT代替VALUES，子查询负责实时解析父ID。如果父节点不存在，这条语句会插入0行而不是报错，应用层可以通过受影响行数判断是否插入成功，这在语义上比插入一个错误数据要安全得多。
还有一个容易被忽视的坑：如果表设计时根节点的父ID用0表示而非NULL，而外键约束又指向本表主键，那么插入根节点时会因为找不到ID为0的行而失败。解决办法是先把根节点插入为NULL，再通过UPDATE改值，或者干脆约定根节点父ID统一为NULL，避免特殊值带来的不一致。
三、批量插入整棵子树：保持层级顺序
实际业务中经常需要一次性插入整棵树，比如初始化一套完整的分类目录。批量插入的核心是顺序问题：必须先插父节点拿到ID，再插子节点。如果使用自增主键，可以在一条多值插入语句中利用LAST_INSERT_ID()配合变量逐级获取：
-- 插入根节点
INSERT INTO department (dept_name, parent_id) VALUES ('总公司', NULL);
SET @root_id = LAST_INSERT_ID();
-- 插入一级部门，父ID使用刚才保存的根节点ID
INSERT INTO department (dept_name, parent_id) VALUES
('技术研发部', @root_id),
('市场运营部', @root_id);
SET @dev_id = LAST_INSERT_ID(); -- 本批次第一条记录的自增ID
-- 在技术研发部下插入二级部门
INSERT INTO department (dept_name, parent_id) VALUES
('后端组', @dev_id),
('前端组', @dev_id);
这里利用了一个特性：多值插入时LAST_INSERT_ID()返回的是第一条插入记录的自增ID。由于InnoDB的自增ID在同一批插入中是连续分配的，后续记录的ID可以推算出来。不过这种推算依赖自增连续性，如果表上有触发器或其他并发写入，建议改用逐条插入加变量记录的方式，虽然慢一点但更可靠。
如果数据量大，用SQL脚本手工维护变量容易出错，更好的方式是把层级数据写进存储过程，通过递归调用实现任意深度的插入：
DELIMITER //
CREATE PROCEDURE insert_node(
IN p_name VARCHAR(50),
IN p_parent INT
)
BEGIN
INSERT INTO department (dept_name, parent_id) VALUES (p_name, p_parent);
END //
DELIMITER ;
-- 调用示例：先建父节点，再用返回的自增ID建子节点
CALL insert_node('华东大区', NULL);
SET @region = LAST_INSERT_ID();
CALL insert_node('上海分公司', @region);
SET @branch = LAST_INSERT_ID();
CALL insert_node('销售一部', @branch);
存储过程的好处是把插入逻辑封装在数据库端，应用代码只需要传名称和父ID参数，减少了网络往返。对于需要频繁动态构建子树的场景，还可以进一步写一个接收JSON层级数据的存储过程，在过程体内解析JSON并递归插入，MySQL 8.0以上版本对JSON函数的支持足以支撑这种写法。
四、插入之后的验证：查询子树与层级校验
数据插进去不代表层级就对，插入后应该做验证。MySQL 8.0支持递归CTE，查询某个节点下的整棵子树非常方便：
WITH RECURSIVE sub_tree AS (
SELECT id, dept_name, parent_id, 1 AS depth
FROM department WHERE id = 1
UNION ALL
SELECT d.id, d.dept_name, d.parent_id, s.depth + 1
FROM department d
JOIN sub_tree s ON d.parent_id = s.id
)
SELECT * FROM sub_tree ORDER BY depth;
这条查询从根节点出发，沿着parent_id不断向下钻取，depth字段直观展示了每个节点所处的层级。如果查询结果中出现了异常深的层级，或者某些节点丢失，就说明插入环节的父ID赋值有问题。
对于还在使用MySQL 5.7及以下版本的场景，递归CTE不可用，可以退而求其次用自连接查询固定深度，或者引入路径枚举模型辅助：给表增加一个path字段，存储从根到当前节点的完整路径（如/1/3/7/）。插入子节点时，path等于父节点path拼接自身ID，这样查子树只需一个LIKE '/1/3/%'条件，代价是移动节点时需要批量更新整个子树的path。邻接表加路径枚举的混合方案，在读写频率均衡的系统中表现相当不错，也是很多成熟系统的实际选择。