邻接表适合写多读少、树浅的场景，路径枚举适合读多写少、查询频繁的深树，选择需权衡查询效率与维护复杂度。
在MySQL中实现高效的树形结构存储与查询，我们通常会考虑两种主流模型：邻接表（Adjacency List）和路径枚举（Path Enumeration，有时也称为物化路径或Materialized Path）。这两种方法各有千秋，选择哪一个往往取决于具体的业务场景和对查询、写入性能的侧重。邻接表模型以其直观和易于维护的特点，在处理简单的父子关系时表现出色；而路径枚举则在需要频繁查询子树或祖先路径时，展现出卓越的查询效率，尽管其在数据维护上会带来一些额外的复杂度。
为了具体说明，我们来分别看看这两种模型是如何在MySQL中构建和操作的。
1. 邻接表模型 (Adjacency List Model)
这是最直观、最简单的树形结构表示方式。每个节点只存储其直接父节点的ID。
表结构示例：
CREATE TABLE categories_adj (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
parent_id INT,
FOREIGN KEY (parent_id) REFERENCES categories_adj(id) ON DELETE CASCADE
);数据插入：
INSERT INTO categories_adj (name, parent_id) VALUES
('电子产品', NULL),
('手机', 1),
('笔记本电脑', 1),
('智能手表', 1),
('苹果', 2),
('华为', 2),
('MacBook Air', 3),
('ThinkPad', 3);查询操作：
SELECT * FROM categories_adj WHERE parent_id = 1; -- 查询'电子产品'的所有直接子类
WITH RECURSIVE ancestors AS (
SELECT id, name, parent_id, 1 AS level
FROM categories_adj
WHERE id = 5 -- 从'苹果'开始
UNION ALL
SELECT c.id, c.name, c.parent_id, a.level + 1
FROM categories_adj c
JOIN ancestors a ON c.id = a.parent_id
)
SELECT id, name, parent_id FROM ancestors;WITH RECURSIVE descendants AS (
SELECT id, name, parent_id, 1 AS level
FROM categories_adj
WHERE id = 1 -- 从'电子产品'开始
UNION ALL
SELECT c.id, c.name, c.parent_id, d.level + 1
FROM categories_adj c
JOIN descendants d ON c.parent_id = d.id
)
SELECT id, name, parent_id FROM descendants;在MySQL 8.0之前，实现递归查询需要依赖存储过程或在应用层进行多次查询，效率会大打折扣。
2. 路径枚举模型 (Path Enumeration Model)
这种模型在每个节点中存储从根节点到当前节点的完整路径。路径通常以分隔符（如
/
.
表结构示例：
CREATE TABLE categories_path (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
path VARCHAR(1000) NOT NULL UNIQUE -- 存储完整路径，如 '/1/2/5/'
);数据插入：
插入时需要计算并存储完整的路径。这通常在应用层完成，或者通过触发器实现。
-- 根节点
INSERT INTO categories_path (name, path) VALUES ('电子产品', '/1/');
-- 子节点
-- 假设'电子产品'的id是1，'手机'的id是2
INSERT INTO categories_path (name, path) VALUES ('手机', '/1/2/');
-- 假设'苹果'的id是5
INSERT INTO categories_path (name, path) VALUES ('苹果', '/1/2/5/');
-- 实际插入时，通常需要先插入父节点，获取其ID和路径，再构建子节点的路径
-- 伪代码示例：
-- parent_id = 1, parent_path = '/1/'
-- INSERT INTO categories_path (name, path) VALUES ('手机', CONCAT(parent_path, new_id, '/'));查询操作：
SELECT *
FROM categories_path
WHERE path LIKE '/1/%' -- 假设父节点路径是 '/1/'
AND LENGTH(path) - LENGTH(REPLACE(path, '/', '')) = (LENGTH('/1/') - LENGTH(REPLACE('/1/', '/', ''))) + 1;
-- 这里的LENGTH计算路径深度，确保只查询直接子节点SELECT * FROM categories_path WHERE '/1/2/5/' LIKE CONCAT(path, '%') AND path != '/1/2/5/'; -- 查询'苹果'的所有祖先
SELECT * FROM categories_path WHERE path LIKE '/1/%'; -- 查询'电子产品'的所有后代
说实话，邻接表模型虽然直观，但在处理复杂的树形查询时，确实会遇到一些性能上的挑战。最显著的瓶颈就是递归查询的效率。在MySQL 8.0之前，如果需要查询一个节点的所有祖先或所有后代，我们不得不依赖存储过程或者在应用层进行多次数据库往返查询。这无疑会增加数据库的负载，并且网络延迟也会让整体性能变得不尽人意。即使是MySQL 8.0引入了递归CTE（Common Table Expression），虽然大大简化了SQL语句，但对于非常深或者非常宽的树，CTE的性能表现仍然可能不如预期，它本质上还是在进行多次迭代，每次迭代都需要扫描和匹配。
此外，索引的局限性也是一个问题。
parent_id
缓解策略：
parent_id
id
parent_id
路径枚举模型在查询上的高效性是毋庸置疑的，特别是对子树的查询，一个简单的
LIKE
UPDATE
更优雅的处理方式：
REPLACE
SUBSTRING
-- 假设节点A (旧路径 '/old/path/A/') 移动到节点B下 (新路径 '/new/path/B/')
-- 节点A的旧路径是 '/old/path/A/'，新路径是 '/new/path/B/A/'
-- 那么所有以 '/old/path/A/' 开头的路径都需要被更新
UPDATE categories_path
SET path = CONCAT('/new/path/B/', SUBSTRING(path, LENGTH('/old/path/') + 1))
WHERE path LIKE '/old/path/A/%';这里需要注意的是，
SUBSTRING
CONCAT
UPDATE
parent_id
is_deleted
选择哪种树形结构存储模型，从来都不是一个“非黑即白”的问题，它更多地是一个权衡和取舍。在我看来，核心在于你的业务场景对查询和写入操作的侧重点，以及树的特性（深度、宽度）。
优先考虑邻接表模型 (Adjacency List) 的场景：
优先考虑路径枚举模型 (Path Enumeration) 的场景：
考虑混合模型或特殊模型（如嵌套集）的场景：
总之，没有银弹。深入理解你的业务需求，预估各种操作的频率和性能要求，再结合MySQL的特性，才能做出最合适的选择。我通常建议从最简单的邻接表开始，如果遇到性能瓶颈，再考虑引入路径枚举或更复杂的模型进行优化。
以上就是如何使用MySQL实现高效的树形结构存储与查询（邻接表、路径枚举）的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
160
收藏
