触发器调用存储过程本身不会栈溢出，但若存储过程中执行UPDATE同表操作，而该表存在BEFORE UPDATE触发器且再次调用同一存储过程，就会形成递归链，耗尽线程栈；错误提示含ERROR 1456或StackOverflowError即为典型特征。
触发器调用存储过程时真的会栈溢出吗
不会——触发器本身不递归调用存储过程，但若存储过程中又显式或隐式触发了同表的触发器（比如 UPDATE 同一表），就构成「触发器递归」。MySQL 默认禁用该行为（sql_mode 不含 NO_ENGINE_SUBSTITUTION 且未开启 log_bin_trust_function_creators 时更易被忽略），但一旦启用（SET GLOBAL log_bin_trust_function_creators = 1 + DELIMITER 写法不当），就可能在无终止条件时层层嵌套调用，耗尽线程栈。
如何确认是不是触发器引发的递归栈溢出
关键看错误信息是否含 ERROR 1456 (HY000): Recursive limit exceeded 或 JVM 层的 StackOverflowError（多见于 DBeaver 等客户端解析触发器元数据时反复回溯）。不是所有“执行卡死”都是栈溢出：先运行 SELECT @@max_sp_recursion_depth, @@session.sql_mode;，再查 SHOW TRIGGERS LIKE 'your_table'; 看是否有 BEFORE UPDATE 触发器调用了含 UPDATE your_table 的存储过程。
最容易踩的坑：触发器 + 存储过程 + 未设防护的递归
- 存储过程里写
UPDATE t1 SET x = ...，而t1上有BEFORE UPDATE触发器，该触发器又调用同一存储过程 → 无限循环 - 误以为
max_sp_recursion_depth只控存储过程，其实它也约束触发器链深度（MySQL 8.0+ 明确计入） - 在 DBeaver 中执行含触发器的语句时切换连接，触发器元数据加载失败（如日志报
Can't get column 'is_hidden'），导致 AST 解析器反复重试 → 客户端栈爆 - MySQL 5.7 下用触发器模拟递归树查询，没加层级计数器或
IF @depth > 5 THEN LEAVE end_loop;类防护
修复和规避的实操动作
立即停用风险链路：DROP TRIGGER IF EXISTS t1_before_update;；然后检查存储过程体，删掉对自身所依赖表的直接 DML 操作。必须保留触发逻辑时，改用应用层控制：
- 加会话级递归开关：
SET @trigger_disabled = 1;，在触发器开头加IF @trigger_disabled THEN LEAVE trig_body; END IF; - 用临时表中转：
CREATE TEMPORARY TABLE tmp_updates AS SELECT id FROM inserted WHERE ...;，再由外部脚本分批处理 - 升级到 MySQL 8.0+ 后，用
WITH RECURSIVE替代触发器递归，避免栈压入 - DBeaver 用户务必升级到 23.3.5+（已修复连接切换时触发器元数据解析的递归 bug）
真正危险的从来不是“有没有触发器”，而是“有没有人在触发器里又去改触发它的那张表”。这点在迁移旧系统时极易被忽略。
