可以，但仅限于同一数据库内的表，且不能操作触发器所属表本身；跨表操作需规避子查询引用被触发表、事务控制语句及非事务性语句，并确保外键完整性。
MySQL触发器能直接更新其他表吗
可以，但仅限于同一数据库内的表，且不能操作触发器所属表本身（比如 AFTER INSERT ON t1 中不能对 t1 再做 INSERT/UPDATE/DELETE，否则会报错 Can't update table 't1' in stored function/trigger because it is already used by statement which invoked this stored function/trigger）。
常见误操作是试图在 BEFORE 触发器里修改当前行以外的同表数据，这会导致循环依赖；而跨表操作必须确保目标表不参与当前 SQL 的执行链路。
触发器里跨表写入的实操限制
MySQL 触发器支持 INSERT、UPDATE、DELETE 操作其他表，但有硬性约束：
-
INSERT INTO t2 SELECT ... FROM t1是允许的，但不能含子查询中引用被触发表（如INSERT INTO t2 SELECT * FROM t1 WHERE id = NEW.id在某些旧版本会报错，建议显式用VALUES()或临时变量） - 不能调用包含事务控制（
COMMIT/ROLLBACK）的存储过程 - 不能使用
SELECT ... INTO OUTFILE、LOAD DATA等非事务性语句 - 如果目标表有外键约束，跨表操作必须满足参照完整性，否则触发器执行失败并回滚整个原语句
替代方案：为什么常推荐用应用层或事件调度
触发器跨表逻辑越复杂，越容易掩盖数据变更路径，导致调试困难。例如：
- 一个
UPDATE orders触发器去同步inventory表，但库存扣减还要校验warehouse_stock，这时嵌套逻辑已超出触发器合理职责 - 主从复制时，基于语句的复制（SBR）可能因触发器中使用
NOW()、UUID()等非确定函数导致主从不一致 - 高并发下多个触发器争抢同一张日志表（如
audit_log），易成为性能瓶颈
更可控的做法是：把跨表逻辑移到应用代码中显式执行，或用 EVENT 定时扫描变更表（如每秒查一次 orders WHERE status = 'shipped' AND synced = 0），再批量更新关联表。
真要写跨表触发器，这些细节不能漏
实际部署前务必验证以下几点：
- 确认 MySQL 版本是否支持所需语法（如
INSERT ... ON DUPLICATE KEY UPDATE在触发器中可用，但 5.7 之前不支持INSERT IGNORE跨库写入） - 所有跨表操作都加
IF EXISTS(SELECT 1 FROM t2 WHERE id = NEW.ref_id)判断，避免因数据缺失导致触发器中断 - 用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获异常，至少记录到错误日志表，否则失败无声 - 测试时关闭
autocommit=0，观察整个事务是否按预期回滚——触发器失败会连带原语句一起回滚，这点和很多人直觉相反
跨表触发器不是不能用，而是它把隐式耦合写进了数据库层，一旦业务变复杂，改起来比重构应用代码还疼。
