MySQL触发器不能直接触发其他触发器，只能通过执行DML语句（如INSERT/UPDATE/DELETE）间接激活目标表上已定义的触发器；跨表可行，但操作自身表会触发ERROR 1442，且主从复制中从库不执行链式触发。
MySQL触发器能间接激活另一张表上的触发器，但「不能直接触发」——因为根本不存在“触发其他触发器”这个动作。所谓链式执行，全是靠 INSERT、UPDATE、DELETE 这类 DML 语句落地后，由 MySQL 自动检查目标表是否定义了匹配事件的触发器，再决定是否拉起。没有 CALL、EXECUTE 或任何显式调用语法。
ERROR 1442 报错说明触发器不是“被调用”，而是“被满足”
很多人在 t1 的触发器里写 INSERT INTO t2 VALUES ()，看到 t2 的触发器也运行了，就以为是“调用了”。其实不是：MySQL 只是在执行完那条 INSERT 后，扫描到 t2 上存在 AFTER INSERT 触发器，且当前上下文允许（比如没被事务回滚、没违反外键），才启动它。
-
ERROR 1442的报错信息很关键：Can't update table 't1' in stored function/trigger because it is already used by statement which invoked this stored function/trigger—— 它不关心你是不是“想调用”，只看语义：只要 DML 操作对象和触发源是同一张表，就硬拦截 - 哪怕你用
SELECT ... INTO @var去查t1，某些旧版本也会触发该错误，因为 MySQL 解析阶段已识别出对本表的引用 - 跨库操作（如
INSERT INTO db2.log_table）完全合法，只要权限和语法没问题；限制只针对“触发它的那张表”
为什么不能像存储过程那样 CALL？
触发器不是可执行对象，它没有入口点，也没有作用域隔离。它的生命周期完全绑定于某张表的某类 DML 事件，由 MySQL 内核在语句执行的特定阶段（BEFORE/AFTER）自动注入执行环境。
- 你写不出
CALL trigger_on_t2()，MySQL 会直接报ERROR 1305 (42000): PROCEDURE db.trigger_on_t2 does not exist—— 因为触发器不在information_schema.ROUTINES里，也不支持 CALL 协议 - 即使两个触发器建在同一个库、同名、同事件类型，只要没有实际 DML 修改目标表，就不会连起来
- 试图用子查询或函数包装 DML 操作也绕不过去：如果函数内部执行了对本表的修改，照样触发
ERROR 1442
主从复制下“链式失效”暴露本质
主库上 t1 → t2 → t3 链路跑通，但从库只重放原始语句（如 INSERT INTO t1），t2 和 t3 的变更都是主库直写进 binlog 的，从库上的对应触发器压根不执行。
- 这说明链式行为不是“触发器调用触发器”，而是“主库上多个独立 DML 语句被依次记录并执行”
- 从库忽略触发器是复制机制设计使然，不是 bug；
SET sql_log_bin = OFF在从库启用只会破坏主从一致性 - 如果业务强依赖日志联动（比如改
orders必须同步记audit_log），必须确保audit_log表也在主库，并由主库触发器直写
最容易被忽略的，是触发器逻辑是否真的走到了那条关键 DML 语句。比如 BEFORE UPDATE 里加了 IF NEW.status = OLD.status THEN LEAVE; END IF;，结果整条 INSERT INTO t2 根本没执行——不是“嵌套失败”，是压根没走到嵌套那步。
