能跨库，但必须显式写全库名表名
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 时容易漏掉这个“幽灵路径”
什么情况下该放弃跨库触发器？
当跨库逻辑开始承担核心职责，比如同步订单状态到风控系统、调用外部日志服务、或涉及多条件分支判断时，就该停手了。这类场景下，触发器会迅速变成维护黑洞：
无法加监控和重试 不能做异步降级 一出错就卡住主事务，拖垮整个写入链路真正难的不是“能不能写”，而是“值不值得让它在数据库里跑”。轻量、确定、低频的补字段或记日志可以留；一旦带业务含义、需容错或对外交互，就该交给应用层或消息队列。
