cte_max_recursion_depth默认1000，但性能瓶颈主因是递归逻辑引发全表扫描、索引失效或中间结果膨胀；递归禁用常因该值被设为0，需检查并手动开启；递归成员禁止group by/order by/limit，层级聚合和排序须移至外层；join方向与索引至关重要，应确保小结果集驱动大表且关联字段有索引；防环必须显式用level限制和路径检测，而非依赖数据纯净；执行计划不反映总迭代耗时，rows暴涨表明中间结果失控，此时调高深度无用，须重构join与索引。
cte_max_recursion_depth 默认值是 1000，但实际性能瓶颈往往不在这个数字本身，而在于你写的递归逻辑是否触发了全表扫描、是否让优化器无法复用索引、是否在每轮迭代中膨胀出大量中间行——这些才是卡死查询的真正原因。
确认递归功能是否真的启用
很多“递归不生效”的问题根本不是语法或数据问题，而是 cte_max_recursion_depth 被设为 0：
- 先执行
SELECT @@cte_max_recursion_depth;，如果返回 0，说明递归被禁用 - 云数据库（如阿里云 RDS、腾讯云 CVM）常默认关闭，需手动开启
- 有
SUPER权限可用SET GLOBAL cte_max_recursion_depth = 1000;；否则只能会话级：SET SESSION cte_max_recursion_depth = 30; - 别忘了检查错误信息：
ERROR 3636 (HY000): Recursive common table expression is not supported就是这个原因
递归成员里不能写 GROUP BY / ORDER BY / LIMIT
MySQL 把递归部分当成“生成器”，不是完整查询。一旦加了这些子句，直接报错，比如 ERROR 3641 或 Recursive member cannot contain GROUP BY：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 层级聚合（如统计每层节点数）必须挪到外层：
SELECT level, COUNT(*) FROM dept_tree GROUP BY level - 排序也一样：递归内部不能
ORDER BY，但最终SELECT * FROM dept_tree ORDER BY level, id完全合法 - 想提前终止？靠
WHERE level 这类条件过滤，而不是在递归分支里写 <code>LIMIT
JOIN 方向和索引决定性能，不是语法漂亮就行
递归执行本质是“上轮结果 → 驱动 JOIN → 生成本轮新行”。如果驱动方没索引，或者 JOIN 方向反了，就会全表扫：
- 错误写法：
FROM dept_tree dt INNER JOIN departments d ON dt.id = d.parent_id——dt每轮都在变大，d.parent_id若无索引，就扫全表 - 正确写法：
FROM departments d INNER JOIN dept_tree dt ON d.parent_id = dt.id——dt是小集合（上轮结果），d是大表，走parent_id索引 -
parent_id字段必须有索引；若常查某节点的所有祖先（向上递归），则id也要建索引
防环必须靠 level + 显式 WHERE，不能指望数据干净
MySQL 不检测环路。哪怕只有一条记录 parent_id = id，递归就会跑满深度上限才中止，CPU 和内存持续飙升：
- 每层必须带
level字段（如0 AS level→dt.level + 1） - 强制加终止条件：
WHERE d.parent_id IS NOT NULL AND dt.level - 更稳妥的做法是加路径字段（如
CONCAT(',', dt.path, d.id, ',')），再用NOT LIKE CONCAT('%,', d.id, ',%')检测环
真正容易被忽略的是：递归 CTE 的执行计划里看不到“迭代次数”，EXPLAIN ANALYZE 只显示单次迭代的估算，但实际耗时是所有轮次叠加的结果。如果你看到 rows 列在递归行里暴涨，说明中间结果集正在失控膨胀——这时调高 cte_max_recursion_depth 不是解法，重构 JOIN 条件和索引才是。
