MySQL存储过程不支持递归自调用，语法解析阶段即报错1424；max_sp_recursion_depth仅控制合法跨过程嵌套深度，设为0表示禁止嵌套；ERROR 1456源于多层合法调用链超限，非自调用导致；树形查询应优先使用WITH RECURSIVE CTE，禁用存储过程递归。
MySQL 存储过程根本不支持递归调用，你写的 CALL proc_name() 自调用，不管 max_sp_recursion_depth 设成多少，都会直接报 ERROR 1424 (HY000): Recursive stored procedures are not allowed。
为什么 SET max_sp_recursion_depth 看起来“没生效”
这个变量不是用来“开启递归”的，它只对合法的嵌套调用链起作用，比如 proc_a → proc_b → proc_c 这种跨过程调用。而自调用（CALL same_proc()）在语法解析阶段就被 MySQL 硬性拦截——根本不会走到深度检查那步。
-
max_sp_recursion_depth = 0是默认值，表示“禁止任何嵌套”，但仅对跨过程调用是软限制 -
SET SESSION max_sp_recursion_depth = 10完全无效，必须用SET GLOBAL max_sp_recursion_depth = 10 - 该设置重启后丢失，要永久生效得写进
my.cnf的[mysqld]段 - 设太高（如 10000）可能耗尽线程栈空间，尤其在没写终止条件的循环体里
报 ERROR 1456 的真实原因和应对方式
ERROR 1456: Recursive limit 0 (as set by the max_sp_recursion_depth variable) was exceeded 表示当前会话中发生了嵌套调用，且层数超出了 max_sp_recursion_depth 设置值（比如设了 10，实际嵌套到了第 11 层）。但它绝不是因为你写了自调用才触发的——而是你调用了另一个过程，那个过程又调用了第三个……形成了一条合法但过深的调用链。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查调用链：确认是否在存储过程中调用了函数、其他存储过程或触发器，再被它们层层调用
- 临时放宽限制：
SET GLOBAL max_sp_recursion_depth = 50（仅限调试，生产慎用） - 更安全的做法：在过程开头加显式层级计数参数，比如
IN level INT DEFAULT 1，每次调用传level + 1，并在入口做IF level > 20 THEN RETURN; END IF; - 避免依赖
@@NESTLEVEL：它返回的是整个会话所有嵌套对象总层数（含触发器、UDF），不稳定不可控
真正想实现树形遍历，别碰存储过程递归
所有“查所有子节点”“找上级路径”类需求，都应该用 WITH RECURSIVE CTE，这是 MySQL 8.0+ 唯一被官方认可、性能可控、语义清晰的方案。
- 必须用
UNION ALL，UNION会强制去重排序，拖慢速度且可能误删合法重复 ID - 递归深度由
cte_max_recursion_depth控制，默认 1000 层，可临时调：SET SESSION cte_max_recursion_depth = 5000 - 加执行超时更可靠：
SET STATEMENT max_execution_time = 2000 FOR WITH RECURSIVE ... -
parent_id字段必须有索引，否则 5 层递归就可能从毫秒变秒级
硬要用存储过程封装树操作？放弃自调用幻想，改用 WHILE + 临时表模拟：建 temp_nodes 插入根节点，循环把当前层子节点 INSERT IGNORE 进来，靠 ROW_COUNT() = 0 退出，而不是靠深度计数——后者容易漏掉深层节点。最易被忽略的一点：这种迭代逻辑必须放在事务内控制，否则并发更新时临时表数据会互相污染。
