触发器能否直接访问其他数据库的表
可以，但仅限于
SELECT、
INSERT、
UPDATE、
DELETE这类 DML 操作，且必须用
db_name.table_name显式指定库名。MySQL 触发器本身不隔离数据库上下文，只要当前用户有对应库表的权限，语法上完全允许跨库操作。
常见错误现象：
ERROR 1142 (42000): INSERT command denied to user或
Unknown table 'other_db.t'——前者是权限不足，后者通常是表不存在或未用库名限定。 触发器定义中所有跨库对象都必须带库名前缀，比如
INSERT INTO other_db.log_table VALUES (...)不能在触发器里执行
USE other_db切换默认库，该语句在触发器中非法
OLD和
NEW伪记录只能引用当前触发事件所在表的列，无法跨库引用其他表字段
跨库写入时的事务一致性如何保障
MySQL 的触发器运行在同一个事务上下文中，跨库 DML 会参与主表所在事务的提交或回滚——前提是所有操作的表都使用 InnoDB 引擎。一旦涉及 MyISAM 表（哪怕只有一张），整个事务就失去原子性：InnoDB 部分可回滚，MyISAM 部分会提前生效，无法撤销。
典型陷阱：开发时本地测试用的是全 InnoDB，上线后某张日志表用了 MyISAM，导致主业务回滚了，但日志已写入，数据对不上。
检查所有被触发器访问的跨库表引擎：SHOW CREATE TABLE other_db.t;避免在触发器中调用存储过程或函数，如果它们内部含跨库操作，事务行为更难追踪 跨库操作越多，锁竞争和死锁风险越高，尤其当多个触发器同时写同一张远程日志表时
触发器中调用跨库视图或函数是否可行
视图可以查，但必须满足两个条件：一是视图定义中所有基础表可被当前用户访问；二是触发器里显式写成
SELECT * FROM other_db.vw_name。函数则受限更多：
DETERMINISTIC函数能跨库调用，但含
READS SQL DATA或
MODIFIES SQL DATA属性的函数，在触发器中调用会被 MySQL 拒绝，报错
ERROR 1419 (HY000)。
这个限制常被忽略，比如封装了一个跨库计数函数
get_user_count(other_db.users)，即使它只读，若声明为
READS SQL DATA，在触发器里调用就会失败。 临时绕过方法：把函数逻辑内联写进触发器 SQL，但会牺牲可维护性 更稳妥的做法是改用存储过程 +
CALL，但注意：存储过程中仍不能执行
COMMIT或
START TRANSACTION，否则触发器报错 跨库视图若含
UNION或子查询，性能开销可能比直查表高得多，需实测
替代方案比硬写跨库触发器更可靠
真要实现多库联动，优先考虑应用层协调或异步消息，而不是靠触发器扛。触发器跨库本质是把耦合从代码移到数据库，出问题更难定位、更难测试、更难回滚。
一个真实案例：某订单库的
after_insert触发器往统计库写汇总数据，某次统计库慢查询拖住整个订单插入事务，TPS 直接腰斩。 用应用代码统一处理主表变更 + 跨库写入，加分布式事务（如 Seata）或最终一致性（发 MQ） 定时任务拉取 binlog 解析变更，再同步到其他库，解耦强、可监控、易重放 如果坚持用触发器，至少把跨库操作封装进单独的存储过程，并在其中加
DECLARE CONTINUE HANDLER捕获异常，避免因远程库不可用导致主表操作失败
跨库触发器不是不能用，而是它的调试成本、权限管理复杂度和故障传播面，远超多数团队预估。真正需要它的时候，往往说明架构上已经埋了坑。
