MySQL存储过程不支持递归调用，自调用必报ERROR 1424，与max_sp_recursion_depth无关；该变量仅限制跨过程嵌套深度，树形查询应优先使用WITH RECURSIVE CTE。
MySQL存储过程根本不支持递归调用，自调用必报 ERROR 1424
你写的 CALL my_proc() 在自己内部调用自己，MySQL 解析器会在语法检查阶段直接拦截，抛出 ERROR 1424 (HY000): Recursive stored procedures are not allowed。这个错误和 max_sp_recursion_depth 完全无关——变量还没机会起作用，执行就终止了。
这不是“深度不够”，而是语法禁止。别试设 max_sp_recursion_depth = 100 或 SET SESSION，它对自调用 0 效果。
max_sp_recursion_depth 管的是跨过程嵌套，不是递归
这个变量只约束合法的「A → B → C」式调用链，比如 proc_a 调 proc_b，proc_b 又调 proc_c。它是个运行时栈深兜底保护，不是递归开关。
-
max_sp_recursion_depth = 0是默认值，表示禁止任何跨过程嵌套（但实际是软限制） - 设为非零值（如
10）后，若嵌套链超过该层数，会报ERROR 1456，而非1424 -
SET SESSION max_sp_recursion_depth = 10无效，必须用SET GLOBAL max_sp_recursion_depth = 10 - 该设置重启 MySQL 后丢失；要永久生效，得写进
my.cnf的[mysqld]段 - 值设太高（如
10000）可能耗尽线程栈空间，尤其在没写终止条件的循环体里
树形查询别硬扛，优先用 WITH RECURSIVE CTE
想查组织架构、分类路径这类层级数据，WITH RECURSIVE 是 MySQL 8.0+ 的标准解法，比拼存储过程嵌套靠谱得多：
- CTE 递归部分可用
OPTION (MAXRECURSION n)显式控制深度（MySQL 用MAX_DEPTH或无限制写法因版本而异，但逻辑可控） - 它是声明式，优化器能剪枝；存储过程是命令式，每层都重编译、切上下文，开销大
- CTE 不涉及过程嵌套，完全绕过
max_sp_recursion_depth和ERROR 1424/1456 - 唯一短板：CTE 不能做 DML（如边遍历边更新父节点状态），此时才考虑用带
@level计数的 WHILE 循环模拟
触发器嵌套也受同一变量限制，但行为更隐蔽
触发器不支持显式调用，但表 A 的触发器修改表 B 数据，可能间接激活表 B 的触发器，形成嵌套链。这种间接嵌套同样受 max_sp_recursion_depth 影响：
- 默认
0时，多层连锁触发大概率在第 10–15 层报Error 1423: Recursive limit reached - 同一张表的触发器若修改自身数据（如 UPDATE 触发器再 UPDATE 同表），会直接报
Error 1420（禁止自更新） - 嵌套越深，事务锁范围越难预测，死锁风险上升；生产环境应尽量避免三层以上触发器链
