艳yyz1. 项目背景与需求分析
在日常开发中，经常会遇到需要查询树形结构数据的场景。比如文件系统中文件夹的层级关系、组织架构中的上下级关系等。传统做法是通过多次查询数据库，先查父节点，再循环查询子节点，这种方式存在明显的性能问题。
以文件夹系统为例，假设我们有以下表结构：
sql复制CREATE TABLE folders (
id INT PRIMARY KEY,
name VARCHAR(100) NOT NULL,
parent_id INT NULL,
FOREIGN KEY (parent_id) REFERENCES folders(id)
);
当我们需要获取某个文件夹及其所有子文件夹时，传统做法是：
- 先查询指定ID的文件夹
- 查询parent_id等于该ID的所有子文件夹
- 对每个子文件夹重复第2步
- 合并所有查询结果
这种方式的缺点是：
- 需要多次数据库查询
- 应用层代码复杂
- 性能随层级深度线性下降
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 递归CTE技术解析
2.1 什么是递归CTE
递归公用表表达式(Recursive Common Table Expression)是SQL标准中定义的一种特殊CTE，它允许CTE引用自身，从而实现对树形或图状数据的递归查询。
MySQL从8.0版本开始支持递归CTE，其基本语法结构如下：
sql复制WITH RECURSIVE cte_name AS (
-- 基础查询(锚成员)
SELECT ... FROM ... WHERE ...
UNION [ALL]
-- 递归部分(递归成员)
SELECT ... FROM ... JOIN cte_name ON ...
)
SELECT * FROM cte_name;
2.2 递归CTE的工作原理
递归CTE的执行分为三个阶段：
- 初始化阶段：执行锚成员查询，生成初始结果集(R0)
- 递归阶段：
- 将前一次迭代的结果(Ri)作为输入
- 执行递归成员查询，生成新的结果集(Ri+1)
- 直到返回空结果集为止
- 最终结果：合并所有迭代结果(R0 ∪ R1 ∪ ... ∪ Rn)
2.3 递归CTE的终止条件
递归CTE会自动在以下情况终止：
- 递归成员返回空结果集
- 达到系统默认的递归深度限制(MySQL默认1000层)
- 显式设置MAXRECURSION选项限制递归深度
3. 具体实现方案
3.1 基础递归查询实现
针对文件夹层级查询需求，我们可以这样实现：
sql复制WITH RECURSIVE folder_tree AS (
-- 锚成员：查询指定ID的文件夹
SELECT id, name, parent_id, 0 AS depth
FROM folders
WHERE id = 123 -- 要查询的文件夹ID
UNION ALL
-- 递归成员：查询所有子文件夹
SELECT f.id, f.name, f.parent_id, ft.depth + 1
FROM folders f
JOIN folder_tree ft ON f.parent_id = ft.id
)
SELECT * FROM folder_tree;
这个查询会返回：
- ID为123的文件夹
- 所有直接子文件夹(depth=1)
- 所有孙文件夹(depth=2)
- 以此类推，直到没有更多子文件夹
3.2 添加层级深度控制
有时我们需要限制查询的层级深度：
sql复制WITH RECURSIVE folder_tree AS (
SELECT id, name, parent_id, 0 AS depth
FROM folders
WHERE id = 123
UNION ALL
SELECT f.id, f.name, f.parent_id, ft.depth + 1
FROM folders f
JOIN folder_tree ft ON f.parent_id = ft.id
WHERE ft.depth < 3 -- 限制最多查询到第3层
)
SELECT * FROM folder_tree;
3.3 添加路径信息
如果需要获取完整的路径信息，可以这样修改：
sql复制WITH RECURSIVE folder_tree AS (
SELECT
id,
name,
parent_id,
0 AS depth,
CAST(name AS CHAR(1000)) AS path
FROM folders
WHERE id = 123
UNION ALL
SELECT
f.id,
f.name,
f.parent_id,
ft.depth + 1,
CONCAT(ft.path, '/', f.name) AS path
FROM folders f
JOIN folder_tree ft ON f.parent_id = ft.id
)
SELECT * FROM folder_tree;
4. 性能优化与注意事项
4.1 索引优化
为确保递归CTE的性能，必须在相关字段上建立索引：
sql复制-- 必须的索引
CREATE INDEX idx_folders_parent ON folders(parent_id);
CREATE INDEX idx_folders_id ON folders(id);
-- 如果经常按名称查询
CREATE INDEX idx_folders_name ON folders(name);
4.2 递归深度控制
MySQL默认递归深度限制为1000层，可以通过设置cte_max_recursion_depth参数调整：
sql复制SET SESSION cte_max_recursion_depth = 2000; -- 调高递归深度限制
对于已知深度的层级结构，建议在WHERE子句中显式限制深度，避免意外情况。
4.3 避免循环引用
如果数据中存在循环引用(如A的父节点是B，B的父节点又是A)，递归查询会陷入无限循环。解决方法：
- 添加循环检测：
sql复制WITH RECURSIVE folder_tree AS (
SELECT
id, name, parent_id,
0 AS depth,
CAST(id AS CHAR(1000)) AS path_ids
FROM folders
WHERE id = 123
UNION ALL
SELECT
f.id, f.name, f.parent_id,
ft.depth + 1,
CONCAT(ft.path_ids, ',', f.id)
FROM folders f
JOIN folder_tree ft ON f.parent_id = ft.id
WHERE FIND_IN_SET(f.id, ft.path_ids) = 0 -- 确保ID未出现过
)
SELECT * FROM folder_tree;
- 使用MAXRECURSION提示(在SQL Server中支持，MySQL不支持)
4.4 大数据量优化
当处理大型树形结构时，可以考虑以下优化：
- 使用物化视图预计算常用路径
- 使用嵌套集模型(Nested Set Model)替代邻接表
- 对于只读场景，考虑使用闭包表(Closure Table)
5. 实际应用案例
5.1 文件系统查询
查询某个文件夹及其所有子文件夹中的文件数量：
sql复制WITH RECURSIVE folder_tree AS (
SELECT id FROM folders WHERE id = 123
UNION ALL
SELECT f.id FROM folders f
JOIN folder_tree ft ON f.parent_id = ft.id
)
SELECT
ft.id,
f.name,
COUNT(file.id) AS file_count
FROM folder_tree ft
JOIN folders f ON ft.id = f.id
LEFT JOIN files file ON file.folder_id = ft.id
GROUP BY ft.id, f.name;
5.2 组织架构查询
查询某个部门及其所有子部门的员工：
sql复制WITH RECURSIVE dept_tree AS (
SELECT id, name FROM departments WHERE id = 5
UNION ALL
SELECT d.id, d.name FROM departments d
JOIN dept_tree dt ON d.parent_id = dt.id
)
SELECT
e.id,
e.name,
e.position,
dt.name AS department
FROM dept_tree dt
JOIN employees e ON e.department_id = dt.id;
5.3 产品分类查询
查询某个产品分类及其所有子分类下的商品：
sql复制WITH RECURSIVE category_tree AS (
SELECT id, name FROM categories WHERE id = 10
UNION ALL
SELECT c.id, c.name FROM categories c
JOIN category_tree ct ON c.parent_id = ct.id
)
SELECT
p.id,
p.name,
p.price,
ct.name AS category
FROM category_tree ct
JOIN products p ON p.category_id = ct.id;
6. 替代方案比较
6.1 多次查询 vs 递归CTE
| 方案 | 优点 | 缺点 |
|---|---|---|
| 多次查询 | 兼容所有MySQL版本 | 网络开销大、代码复杂、性能差 |
| 递归CTE | 单次查询、性能好、代码简洁 | 需要MySQL 8.0+ |
6.2 递归CTE vs 存储过程
| 方案 | 优点 | 缺点 |
|---|---|---|
| 递归CTE | 声明式语法、可移植性好 | 功能相对有限 |
| 存储过程 | 灵活性高、可处理复杂逻辑 | 代码维护成本高、可移植性差 |
6.3 递归CTE vs 应用层递归
| 方案 | 优点 | 缺点 |
|---|---|---|
| 递归CTE | 性能好、减少网络传输 | 需要数据库支持 |
| 应用层递归 | 不依赖数据库特性 | 网络开销大、性能差 |
7. 常见问题与解决方案
7.1 递归CTE性能差
可能原因：
- 缺少必要的索引
- 递归深度过大
- 中间结果集过大
解决方案：
- 确保parent_id和id字段有索引
- 限制递归深度
- 只选择必要的列，避免SELECT *
7.2 出现重复记录
可能原因：
- 数据中存在循环引用
- UNION ALL保留了重复记录
解决方案：
- 使用上述循环检测技术
- 如果需要去重，使用UNION代替UNION ALL
7.3 MySQL版本兼容性问题
解决方案：
- 对于MySQL 5.7及以下版本，考虑：
- 使用存储过程实现递归
- 使用应用层递归查询
- 升级到MySQL 8.0+
7.4 递归深度限制
解决方案：
- 对于已知深度的结构，显式限制递归深度
- 调整cte_max_recursion_depth参数
- 考虑使用非递归算法(如嵌套集模型)
8. 最佳实践建议
- 始终添加索引：确保parent_id和id字段有索引
- 限制返回列：只选择必要的列，减少数据传输量
- 控制递归深度：对于已知深度的结构，显式限制深度
- 添加循环检测：防止数据问题导致无限递归
- 考虑替代方案：对于特别大的层次结构，考虑使用嵌套集或闭包表
- 版本兼容性：明确应用需要支持的MySQL版本
- 性能测试：对生产环境中的递归查询进行性能测试
通过合理使用递归CTE，我们可以用一条SQL语句高效地查询树形结构数据，避免了多次查询带来的性能问题，同时保持代码的简洁性和可维护性。