MySQL 8.0中递归CTE能且应完全替代存储过程递归，因其在性能、可维护性与并发安全性上全面占优；存储过程递归依赖临时表引发多次I/O、无法利用索引、易冲突出错，而WITH RECURSIVE内存迭代、支持索引、语法严谨但需严守四条约束。
MySQL 8.0 中递归 CTE 能完全替代存储过程实现的递归查询，而且必须替代——因为存储过程递归在性能、可维护性和并发安全性上全面劣于 WITH RECURSIVE。
为什么存储过程递归会失效
存储过程模拟递归本质是“循环 + 临时表”，它绕过了优化器对层级数据的天然建模能力：
- 每次
INSERT INTO temp_table都触发一次磁盘 I/O，5 层递归就可能产生 31 次写操作（2⁵−1），而WITH RECURSIVE全程在内存中迭代 - 临时表无法复用主表索引，
EXPLAIN显示为全表扫描；CTE 递归中INNER JOIN subordinates ON e.manager_id = s.id可命中idx_manager索引 - 并发执行时，即使加
CONNECTION_ID()拼接表名，仍可能因连接池复用导致临时表冲突 - 错误堆栈只报
REPEAT块末尾，无法定位到第几轮递归出错
WITH RECURSIVE 的四条硬性语法约束
写错任意一条，轻则结果缺失，重则报 ERROR 3636 (HY000): Recursive query aborted after 1001 iterations：
- 必须显式写
WITH RECURSIVE，漏掉RECURSIVE关键字直接语法报错 - 锚成员和递归成员之间只能用
UNION ALL；用UNION会去重，导致子节点重复 ID 被合并，树形结构塌陷 - 递归成员的
FROM或JOIN子句中，CTE 名称只能出现一次，且不能在LEFT JOIN右侧或子查询里 - 终止条件必须由列值驱动，例如
ON c.parent_id = t.id；禁止用NOW()、RAND()或用户变量
向上递归（找父级）与向下递归（找子级）的关键差异
两者 JOIN 方向相反，但都依赖同一张表的同一索引，只是使用方式不同：
- 向下递归（查所有下属）：
INNER JOIN employees e ON e.manager_id = s.id→ 依赖manager_id字段上的索引 - 向上递归（查所有上级）：
INNER JOIN categories c ON c.id = p.parent_id→ 依赖id主键索引，无需额外索引 - 向上递归更安全：因
parent_id为空时自然终止；向下递归若漏判manager_id IS NOT NULL，可能把顶级员工当作自己的下属 - 路径拼接建议用
CAST(... AS CHAR(500))显式声明长度，避免隐式转换截断
递归深度失控的真实原因不是配置太小
调大 cte_max_recursion_depth 是掩耳盗铃。真正卡死的根源藏在数据里：
- 父子自环：
SELECT id FROM your_table WHERE parent_id = id，这种记录会让某一层永远匹配自己 - 空值语义混乱：
parent_id是INT类型，但业务误存了' '字符串，导致JOIN永远失败，递归永不终止 - 初始查询与递归查询数据域重叠：锚点用了
WHERE id = 1001，递归部分却没排除该 ID，下一轮又捞出同一条 - 最稳妥的防护是在递归分支加
WHERE t.level < 10，用业务可接受的最大深度兜底，而不是依赖系统变量
真正棘手的从来不是语法怎么写，而是数据里藏着的隐性环、类型混用、空值歧义——这些不会在 CREATE PROCEDURE 时报警，却会在某次 SELECT 时突然卡死整个连接。
