MySQL触发器不能直接触发其他触发器，因其无调用接口、非可执行对象；所谓链式执行实为DML语句落地后由MySQL自动检查并激活目标表触发器，属被动条件满足，非主动调用。
MySQL触发器根本不能“直接触发另一个触发器”——这不是功能缺失，而是设计上就没有这个机制。所谓递归或链式执行，全是靠 INSERT、UPDATE、DELETE 这类语句落地后，由 MySQL 自动检查并拉起目标表的触发器，不是调用，是条件满足后的被动激活。
为什么写 CALL trigger_name() 会报错？
触发器不是可执行对象，它没有入口点，也不在 information_schema.ROUTINES 中注册。你尝试 CALL 或 EXECUTE 任何触发器名，MySQL 都会直接返回：ERROR 1305 (42000): PROCEDURE db.trigger_name does not exist。这不是权限或配置问题，是语法层面不支持。
-
TRIGGER不是存储过程（PROCEDURE）或函数（FUNCTION），无法被显式调用 - 所有“看起来像调用”的行为，本质都是 DML 语句执行后触发的二次自动扫描
- 哪怕两个触发器建在同一库、同名、同事件类型，只要没实际 DML 修改目标表，就不会连起来
为什么在触发器里改本表会立刻报 ERROR 1442？
这不是递归深度限制，而是 MySQL 的硬性执行栈保护：只要当前 SQL 正在修改某张表，该表上的触发器就禁止再对该表做任何 DML 操作。报错信息里的 “already used by statement which invoked this stored function/trigger” 指的就是这个语义锁定。
- 哪怕只是
SELECT ... INTO @var查本表，旧版本也会在解析阶段拦截 -
max_sp_recursion_depth对触发器完全无效，设成 100 也拦不住ERROR 1442 - 封装进存储过程再调用？照样报错——限制发生在执行上下文，不是调用路径
- 跨库操作（如
INSERT INTO db2.t2）完全合法，限制只针对“触发源表”本身
为什么主从复制下链式行为会失效？
主库上 t1 → t2 → t3 看似跑通，但从库只重放原始语句（比如 INSERT INTO t1），t2 和 t3 的变更都是主库直写进 binlog 的，从库上的对应触发器压根不执行。
- 这反向证明：链式不是“触发器调用触发器”，而是“主库上多个独立 DML 语句被依次记录并执行”
-
SET sql_log_bin = OFF在从库临时启用，会破坏主从一致性，不可用于生产 - 如果业务强依赖级联日志（如操作
t1必须同步记审计到sys_log.audit_log），得确保目标表也在主库，并由主库触发器直写
真正容易被忽略的是：触发器逻辑是否真的走到了那条关键 DML 语句。比如 BEFORE UPDATE 里加了条件判断，结果因 NEW.status = OLD.status 直接跳过后续 INSERT INTO t2，整条链就断了——它不是“没嵌套”，是压根没走到嵌套那步。
