大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

你有没有写过这样的代码：查组织架构，先查顶层部门，再循环查子部门，每层写一个

循环。部门深度是5层就写5个循环，深度不确定就写

这种写法，代码难看、性能差、还容易出bug。每次看到这种代码我都想问一句：

递归CTE是SQL标准中处理树形结构的官方解法，MySQL 8.0+、PostgreSQL、SQL Server都原生支持。树形结构查询有好几种写法，每种写法各有优劣：

递归CTE可能是树形查询的最优解——语法简单清晰、一次搞定、不需要额外维护表结构。我把三个最常用的场景拆开讲，看完就能上手。

递归CTE（Recursive Common Table Expression）说白了就是一个能“自己调用自己”的临时查询结果集。

连接起来。数据库执行的时候，先跑锚点拿到第一层结果，然后拿着这些结果去跑递归成员，拿到第二层，再拿第二层去跑第三层……直到再也找不到新数据为止。

从起点出发，每次拿当前查到的结果去查下一层，一层层往下展开，直到触底为止。

 就像玩一个“点开一个文件夹，自动展开它里面所有子文件夹”的游戏，只不过这个游戏是数据库帮你自动完成的。

二、场景一：遍历组织架构树——最基础的用法

。要查出某个部门及其所有下级：

WITH RECURSIVE dept_tree AS (
    -- 锚点：从根部门开始
    SELECT id, name, parent_id, 0 AS depth
    FROM department
    WHERE id = 1   -- 指定根节点ID
    
    UNION ALL
    
    -- 递归：找子部门
    SELECT d.id, d.name, d.parent_id, dt.depth + 1
    FROM department d
    INNER JOIN dept_tree dt ON d.parent_id = dt.id
)
SELECT * FROM dept_tree ORDER BY depth, id;

字段记录层级深度，方便在应用层做缩进展示。

 一次查询搞定所有层级，不用在应用层写循环，不用反复建立数据库连接，性能提升肉眼可见。

三、场景二：面包屑导航——从叶子节点往上找

电商网站的商品分类、博客的评论嵌套、系统的菜单路径——这些都需要“从当前位置追溯到根”。

比如给一个商品分类ID，生成“首页 > 手机 > 智能手机 > iPhone 15”这样的面包屑：

WITH RECURSIVE breadcrumb AS (
    -- 锚点：从当前分类开始
    SELECT id, name, parent_id, 1 AS level
    FROM category
    WHERE id = 123   -- 指定当前分类ID
    
    UNION ALL
    
    -- 递归：往上找父级
    SELECT c.id, c.name, c.parent_id, b.level + 1
    FROM category c
    INNER JOIN breadcrumb b ON c.id = b.parent_id
)
SELECT * FROM breadcrumb ORDER BY level DESC;

让根节点排在前面，直接就能渲染面包屑。一层SQL搞定原本需要递归查询或多次查库才能完成的事情。

四、场景三：带路径的完整子树——行政区域查询

有时候不仅要查出所有下级节点，还要知道每个节点的完整路径。比如查询某个省下的所有市、区、街道：

WITH RECURSIVE region_tree AS (
    -- 锚点：从指定省份开始
    SELECT id, name, parent_id, 0 AS depth,
           CAST(name AS CHAR(1000)) AS path
    FROM region
    WHERE id = 440000   -- 广东省
    
    UNION ALL
    
    -- 递归：找下级行政区
    SELECT r.id, r.name, r.parent_id, rt.depth + 1,
           CONCAT(rt.path, ' > ', r.name)
    FROM region r
    INNER JOIN region_tree rt ON r.parent_id = rt.id
)
SELECT * FROM region_tree ORDER BY depth, id;

逐层拼接，最终得到类似“广东省 > 广州市 > 天河区”的完整路径。

这个模式在电商的SPU-SKU层级、BOM物料清单、组织权限树等场景中都非常实用。

五、递归CTE的性能陷阱与避坑指南

递归CTE虽强，但用不好也会踩坑。

陷阱1：缺少索引，每层全表扫描

递归查询的每一层都会执行一次

没有索引，每一层都要扫描全表，性能急剧下降。

上有索引。对于频繁查询树形结构的表，这是必须的。

都可以，但要确保和业务数据一致。如果业务中用

陷阱3：数据中存在环，导致无限递归

这样的环，递归CTE会无限执行下去。

：限制递归深度。在递归成员中添加

当树形结构数据量极大（百万级节点）且查询频繁时，递归CTE可能成为性能瓶颈。

：考虑用闭包表（Closure Table）或路径枚举（Path Enumeration）方案来替代递归CTE。这两种方案以空间换时间，适合读多写少的场景。

递归CTE是处理树形结构查询的标准写法，三个核心场景覆盖了大部分日常需求：

递归CTE的语法看起来有点吓人，但拆开看就是“锚点 + UNION ALL + 递归关联”三部分。写的时候记住三件事：

锚点写对、索引建好、防环做好

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

你有没有写过这样的代码：查组织架构，先查顶层部门，再循环查子部门，每层写一个for循环。部门深度是5层就写5个循环，深度不确定就写while循环不断查库。

递归CTE实战：用SQL搞定树形结构查询，告别“写死”代码

组织架构、商品分类、菜单权限、BOM清单——树形结构查询是日常开发中高频出现的需求。很多开发者的做法是“写死层级”或“循环查库”，代码又臭又长，性能还差。递归CTE是解决这类问题的标准写法，但很多人一看到WITH RECURSIVE就觉得头大。本文从三个真实场景出发，手把手教读者写出能直接用的递归CTE，并讲清楚执行机制和性能陷阱。

架构设计

"递归CTE是SQL处理树形结构的高效方案，避免循环查库性能问题。本文详解递归CTE三大应用场景：组织架构遍历、面包屑导航和行政区域查询，并分享索引优化、防环等实用技巧。MySQL8.0+等主流数据库均支持，一次查询即可完成多级数据处理。"

PostgreSQL

数据库

大数据

腾讯云数据库特惠，新用户首单0.5折起


sqlserver

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

递归CTE实战：用SQL搞定树形结构查询，告别“写死”代码

递归CTE实战：用SQL搞定树形结构查询，告别“写死”代码

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐