MySQL触发器支持跨库操作，但必须显式写全库名表名；禁止在触发器中对触发它的表执行任何DML操作，否则报ERROR 1442；跨库需注意权限、事务一致性及隐性依赖风险。
能跨库，但必须显式写全库名表名
MySQL触发器完全支持跨库操作，前提是语句中明确写出 db_name.table_name。触发器体本质是普通 SQL 执行环境，只要权限够、语法对，INSERT INTO audit_db.audit_log 或 UPDATE sales.product SET stock = stock - NEW.qty 都合法。它不禁止跨库，只禁止操作「正在被触发的那张表」——这是关键分界线。
ERROR 1442 报错不是跨库问题，而是动了本表
常见错误 Can't update table 'xxx' in stored function/trigger（错误码 ERROR 1442）常被误读为“不能跨表/跨库”，其实它只针对一种行为：在触发器里对触发它的那张表做任何 DML（包括 SELECT COUNT(*)）。哪怕只是查本表做判断，在某些 MySQL 版本中也会触发该限制。
- ❌ 错误示例：
DELETE FROM OperationLog LIMIT 1（在OperationLog的触发器里删自己） - ✅ 正确替代：用
EVENT调度清理，或把逻辑移到应用层控制
跨库操作的三个隐形陷阱
跨库看着简单，线上出问题往往不在语法，而在权限、事务边界和隐性依赖：
-
权限陷阱：触发器以
DEFINER身份运行，不是调用者。若定义者是'root'@'localhost'，但业务账号没权限写log_db.log_table，就会静默失败 - 事务一致性有保障：跨库操作仍包裹在原事务中，只要目标库也是 InnoDB，失败会一起回滚；但若目标库是 MyISAM，则无原子性保证
-
不可见性风险：业务代码没碰
config_db.default_settings，但数据却变了——查 Bug 时容易漏掉这个“幽灵路径”
什么情况下该放弃跨库触发器？
当跨库逻辑开始承担核心职责，比如同步订单状态到风控系统、调用外部日志服务、或涉及多条件分支判断时，就该停手了。这类场景下，触发器会迅速变成维护黑洞：
- 无法加监控和重试
- 不能做异步降级
- 一出错就卡住主事务，拖垮整个写入链路
真正难的不是“能不能写”，而是“值不值得让它在数据库里跑”。轻量、确定、低频的补字段或记日志可以留；一旦带业务含义、需容错或对外交互，就该交给应用层或消息队列。
