递归CTE与嵌套子查询本质不同，不可直接比效率：前者用于动态深度层级遍历，后者是静态展开的一次性结构；仅当最大深度已知且较小时才可等效对比，且均依赖索引优化。
递归CTE不是“比嵌套子查询更高效”，而是解决不同问题的工具；拿它和嵌套子查询比效率，多数时候是在拿锤子比螺丝刀——场景错配。
为什么不能直接对比递归CTE和嵌套子查询的执行时间
嵌套子查询（比如 SELECT * FROM (SELECT * FROM (SELECT ...))）是静态展开的一次性结构，数据库优化器会尝试扁平化或转成 JOIN；而递归 CTE（WITH RECURSIVE）是动态迭代机制，用于处理未知深度的层级关系。两者根本不在同一执行模型里：
- 嵌套子查询没有“循环”语义，它不支持树形遍历、路径展开或任意深度下钻
- 递归 CTE 无法被简单替换成固定层数的嵌套子查询——你得预估最大深度，硬写 5 层 JOIN 或 5 个
UNION ALL，且一换需求就得改 SQL - EXPLAIN 输出里，嵌套子查询常表现为多个独立扫描节点，而递归 CTE 显示为单个
Recursive Union节点，执行计划结构完全不同
真要对比，必须限定在同一业务场景下
只有当你要查“某节点下所有后代”，且已知最大深度 ≤ 3 层时，才可能写出等效的嵌套方案（如自连接 3 次），此时可实测对比。但要注意：
- MySQL 8.0 默认禁用递归，需先执行
SET SESSION cte_max_recursion_depth = 100 - PostgreSQL 需显式加
SEARCH DEPTH FIRST BY id才能保证顺序和剪枝生效 - 锚成员（初始查询）必须走索引，否则递归第一轮就全表扫，后续每轮都在膨胀结果集上匹配
- 嵌套方案中，第 3 层 JOIN 的 ON 条件若没索引，性能会断崖式下跌；而递归 CTE 的递归成员 WHERE/JOIN 条件同样依赖索引，否则每轮都变全量匹配
看执行计划比看耗时更可靠
单纯比 SELECT ... 耗时容易误导，因为客户端网络、缓存、并发干扰太大。重点看 EXPLAIN ANALYZE 输出里的关键指标：
- 递归 CTE：关注
CTE Scan下的Actual Loops次数（即递归轮数），以及每轮的Actual Rows是否指数增长 - 嵌套方案：看是否出现
Nested Loop+Seq Scan组合，特别是内层扫描是否重复执行（Actual Loops > 1） - 两者都应检查
Buffers使用量——递归 CTE 物化中间结果会多占内存，但避免了多次解析与网络往返 - 若递归 CTE 出现
Work-memory exhausted错误，说明物化结果超限，需调大work_mem（PostgreSQL）或cte_max_recursion_depth（MySQL）
真正影响效率的往往是数据建模和索引
无论选哪种写法，如果父子关系字段（如 parent_id）没索引，或者锚查询条件（如 WHERE type = 'dept'）无法命中索引，性能瓶颈根本不在语法层面：
- 递归 CTE 的锚成员慢 → 后续所有轮次都慢
- 嵌套方案中任意一层 JOIN 条件无索引 → 整个链路退化为笛卡尔积
- 用
EXISTS替代IN (subquery)常能绕过子查询物化开销，但这和递归 CTE 完全无关 - 对超深树（如推荐链 > 20 层），即使递归 CTE 正确，也建议在应用层加深度限制或改用闭包表（Closure Table）
递归 CTE 的优势只在“动态深度+声明式表达”这个窄缝里成立；一旦脱离树形、路径、序列这类场景，强行套用反而拖慢查询。别迷信语法，先确认你面对的是不是真正的层级问题。
