MySQL存储过程不支持递归调用，自调用会直接报错ERROR 1424；max_sp_recursion_depth仅限制合法嵌套调用深度，对自调用无效；实现树形遍历应优先使用WITH RECURSIVE CTE。
MySQL 存储过程根本不支持递归调用，max_sp_recursion_depth 不是用来“开启”或“限制递归”的，而是防止嵌套调用过深导致栈溢出的兜底保护。你写 CALL proc_name() 自调用，不管这个变量设成多少，都会直接报错 ERROR 1424 (HY000): Recursive stored procedures are not allowed。
为什么 SET max_sp_recursion_depth 没用？
这个变量只对「合法的嵌套调用链」起作用，比如 proc_a → proc_b → proc_c 这种跨过程调用。它不干预「自调用」行为，因为 MySQL 在语法解析阶段就禁止了存储过程调用自己——根本不会走到深度检查那步。
-
max_sp_recursion_depth = 0是默认值，表示“禁止任何嵌套”，但实际中它只是软限制；设为非 0（如10）只在嵌套层数超限时抛ERROR 1456 - 会话级设置无效：
SET SESSION max_sp_recursion_depth = 10不生效，必须用SET GLOBAL max_sp_recursion_depth = 10 - 重启后失效，要永久生效得写进
my.cnf的[mysqld]段 - 值设太高（如
10000）可能耗尽线程栈空间，尤其在没写终止条件的循环体里
真正想实现树形遍历，该用 WITH RECURSIVE CTE
MySQL 8.0+ 原生支持递归查询，这是唯一被官方认可、性能可控、语义清晰的方案。所有“递归查上级/下级”的需求，都应该优先转成 CTE 写法。
- 必须用
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 ...，毫秒级中断，比等满 1000 层靠谱 - 关键字段（如
parent_id）必须有索引，否则 5 层递归就可能从毫秒变秒级
如果硬要封装在存储过程中，只能用 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进来 - 循环退出条件是没新数据插入，不是靠深度计数——避免人为漏掉深层节点
- 别在循环里反复
SELECT ... INTO变量，大数据量下性能断崖式下跌
max_sp_recursion_depth 和触发器完全无关
有人想靠它放开触发器递归，这是典型误用。触发器递归被 MySQL 硬编码禁止，错误是 ERROR 1442 或 ERROR 1422，跟这个变量毫无关系。哪怕你把它设成一百万，只要触发器里更新了自己监听的表，立刻报错。
真要模拟多层联动，得用标记字段（如 is_cascading TINYINT DEFAULT 0）或者中间表中转——这些控制逻辑全在 SQL 层外，数据库只负责执行明确指令。越试图在存储过程或触发器里塞复杂流程，越容易遇到不可调试的死循环和权限陷阱。
