如何修复MySQL存储过程因递归调用层数过多导致的崩溃？

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）。这不是递归，是嵌套；不是你主动写的“递归逻辑”，而是过程之间意外形成了调用环。

1. 检查所有被调用的过程体，确认有没有隐式调用其他过程（尤其是通过动态 SQL 或触发器间接触发）
2. 用 SHOW PROCEDURE STATUS 查看过程定义，再人工梳理调用关系图
3. ERROR 1456 一定伴随实际的嵌套调用链，不是单个过程里写了个 CALL my_proc() 就能触发的

为什么 SET max_sp_recursion_depth = 100 没用

这个变量只对新建立的连接生效，且必须用 SET GLOBAL max_sp_recursion_depth = 100 —— SET SESSION 完全无效。更重要的是，它不解决根本问题：

1. 设成 100 只会让原本报 ERROR 1456 的嵌套链多跑几层，但可能更快耗尽线程栈，导致连接异常断开
2. 重启 MySQL 后该设置丢失，除非写进 my.cnf 的 [mysqld] 段
3. 值设太高（如 1000+）在无终止条件的循环体中极易引发 Stack overflow，表现为客户端静默断连或 MySQL 进程 crash

真正需要树形遍历？别碰存储过程递归

所有“查所有子节点”“向上找父路径”类需求，在 MySQL 8.0+ 中唯一正确解法是 WITH RECURSIVE CTE：

1. 必须写 RECURSIVE 关键字，漏了语法直接报错
2. 锚点和递归部分字段数、类型、顺序必须完全一致，否则报 ERROR 1248
3. 连接字段（如 parent_id）必须有索引，否则 5 层递归就可能从毫秒变秒级
4. 用 UNION ALL，UNION 会强制去重排序，拖慢且可能误删重复 ID
5. 控制深度用 SET SESSION cte_max_recursion_depth = 5000，防死循环加 SET STATEMENT max_execution_time = 2000 FOR ...

非要在存储过程中封装树操作？只能用 WHILE + 临时表

如果业务强依赖事务上下文（比如边查子节点边更新状态），那就放弃“递归”幻想，改用迭代模拟：

1. 先建 CREATE TEMPORARY TABLE temp_nodes (id INT PRIMARY KEY)
2. 插入根节点：INSERT INTO temp_nodes SELECT id FROM tree WHERE id = ?
3. 用 WHILE ROW_COUNT() > 0 DO ... END WHILE 循环：每次把 temp_nodes 中节点的子节点 INSERT IGNORE 进来
4. 退出条件是没新数据插入，不是靠人工计数——避免漏掉深层节点
5. 整个过程不依赖 max_sp_recursion_depth，也不触发 ERROR 1424 或 1456

最常被忽略的一点：所谓“递归需求”，95% 都是误判。先确认你是否真的在调用另一个过程，而不是在同一个过程里写了 CALL same_name() —— 后者永远卡在解析阶段，连变量设置的机会都没有。