mysql存储过程不支持递归调用，首次自调用即报error 1424；error 1456源于合法跨过程嵌套调用链超深，非递归所致；树形查询应优先使用with recursive cte，禁用存储过程递归。
MySQL 存储过程根本不会因“递归调用层数过多”而崩溃——它压根不允许递归调用，第一次自调用就直接报错 ERROR 1424，连执行都进不去，更谈不上“层数过多”或“崩溃”。
为什么你看到 ERROR 1456 并不表示你在递归
报 ERROR 1456: Recursive limit 0 was exceeded 的真实场景是：你写了多个存储过程，比如 proc_a → proc_b → proc_c → … 这种跨过程的合法嵌套调用链，且总深度超过了 max_sp_recursion_depth 设置值（默认为 0）。这不是递归，是嵌套；不是你主动写的“递归逻辑”，而是过程之间意外形成了调用环。
- 检查所有被调用的过程体，确认有没有隐式调用其他过程（尤其是通过动态 SQL 或触发器间接触发）
- 用
SHOW PROCEDURE STATUS查看过程定义，再人工梳理调用关系图 -
ERROR 1456一定伴随实际的嵌套调用链，不是单个过程里写了个CALL my_proc()就能触发的
为什么 SET max_sp_recursion_depth = 100 没用
这个变量只对新建立的连接生效，且必须用 SET GLOBAL max_sp_recursion_depth = 100 —— SET SESSION 完全无效。更重要的是，它不解决根本问题：
- 设成 100 只会让原本报
ERROR 1456的嵌套链多跑几层，但可能更快耗尽线程栈，导致连接异常断开 - 重启 MySQL 后该设置丢失，除非写进
my.cnf的[mysqld]段 - 值设太高（如 1000+）在无终止条件的循环体中极易引发
Stack overflow，表现为客户端静默断连或 MySQL 进程 crash
真正需要树形遍历？别碰存储过程递归
所有“查所有子节点”“向上找父路径”类需求，在 MySQL 8.0+ 中唯一正确解法是 WITH RECURSIVE CTE：
- 必须写
RECURSIVE关键字，漏了语法直接报错 - 锚点和递归部分字段数、类型、顺序必须完全一致，否则报
ERROR 1248 - 连接字段（如
parent_id）必须有索引，否则 5 层递归就可能从毫秒变秒级 - 用
UNION ALL，UNION会强制去重排序，拖慢且可能误删重复 ID - 控制深度用
SET SESSION cte_max_recursion_depth = 5000，防死循环加SET STATEMENT max_execution_time = 2000 FOR ...
非要在存储过程中封装树操作？只能用 WHILE + 临时表
如果业务强依赖事务上下文（比如边查子节点边更新状态），那就放弃“递归”幻想，改用迭代模拟：
- 先建
CREATE TEMPORARY TABLE temp_nodes (id INT PRIMARY KEY) - 插入根节点：
INSERT INTO temp_nodes SELECT id FROM tree WHERE id = ? - 用
WHILE ROW_COUNT() > 0 DO ... END WHILE循环：每次把temp_nodes中节点的子节点INSERT IGNORE进来 - 退出条件是没新数据插入，不是靠人工计数——避免漏掉深层节点
- 整个过程不依赖
max_sp_recursion_depth，也不触发ERROR 1424或1456
最常被忽略的一点：所谓“递归需求”，95% 都是误判。先确认你是否真的在调用另一个过程，而不是在同一个过程里写了 CALL same_name() —— 后者永远卡在解析阶段，连变量设置的机会都没有。
