mysql 5.7存储过程嵌套爆栈主因是调用链过深而非数据量大：每层call压栈帧，thread_stack默认仅256kb，超100层即触发error 1456或断连；需查select @@max_sp_recursion_depth，非零则设为20并优先改用临时表+while循环替代递归。
MySQL 5.7 存储过程嵌套调用为什么会爆栈？
不是数据太大，而是调用链太深——MySQL 解析和执行每个 CALL 都要压一层栈帧，线程栈（thread_stack）默认仅 256KB，撑不住 100 层以上的递归。一旦触发 ERROR 1456 (HY000): Recursive limit exceeded 或直接断连，说明已到临界点。
怎么查和设 max_sp_recursion_depth？
这个参数控制存储过程递归深度上限，但默认是 0（禁用）。线上误开后没加防护，就是定时炸弹。
- 立即查当前值：
SELECT @@max_sp_recursion_depth; - 若返回非零值（比如 1000），必须评估业务是否真需要递归——绝大多数组织树、类目层级 ≤ 20 层就足够
- 安全设限：
SET max_sp_recursion_depth = 20;（会话级，连接重连即失效） - 如需全局生效，得写进
my.cnf并重启，但不推荐；更稳妥的是在应用层或过程开头加防护
递归逻辑怎么改写才不依赖深度嵌套？
别硬写 CALL proc(n-1)，MySQL 5.7 不支持 CTE 递归，靠堆 CALL 只会让问题更隐蔽。
- 用临时表 + 循环变量模拟：把待处理 ID 列表先写入
tmp_nodes，再用WHILE查一层、存一层、删一层，避免调用链增长 - 状态码中转替代深层
IF ... ELSEIF：声明DECLARE status_code TINYINT DEFAULT 0;，用单次SELECT查配置表得出分支依据，后续只做IF status_code = 1 THEN ... - 真复杂就拆：把“查父节点 → 查子节点 → 更新路径”拆成三个独立过程，用
CALL分段调用，每段深度 ≤ 3
容易被忽略的客户端侧风险
不只是 MySQL 服务端会崩——DBeaver、Navicat 等 Java 客户端解析超深嵌套 SQL 时，JVM 栈也可能 StackOverflowError，报错却显示为 “Lost connection”。这种问题查 SHOW PROCESSLIST 看不到异常，得从客户端日志反推。
上线前务必用最大可能深度（比如部门树 50 层）跑一遍，观察服务端 error log 和客户端是否静默断连。
