不能。MySQL触发器禁止跨库访问，所有表名必须属于当前数据库，SELECT/INSERT等语句中使用db2.table_name会直接报错；替代方案需将跨库逻辑移至应用层、事件调度或消息队列。
MySQL触发器里能直接写 db2.table_name 吗？
不能。MySQL触发器语法明确禁止在 SELECT、INSERT、UPDATE 或 DELETE 语句中引用其他数据库的表（即跨库访问），哪怕用 db2.t 这种三段式标识符也会报错：ERROR 1362 (HY000): Updating of <code>NEW row is not allowed in after trigger（如果误操作 NEW）或更常见的 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger —— 跨库只是让这个限制更早暴露。
根本原因不是权限或配置问题，而是 MySQL 触发器执行时被锁死在当前事务上下文，且不允许触发器内再打开对其他表（含跨库表）的隐式读写依赖。
- 触发器内所有表名必须是当前数据库内的，不带库名前缀（或显式用
current_db().table，但效果等同） -
INSERT INTO db2.t ...、SELECT * FROM db2.t等写法会直接报错，无法绕过 - 即使两个库在同一个实例、用户有全库权限，也不行
想让触发器“感知”其他库的数据，实际可行的替代方案
只能把跨库逻辑移出触发器，在应用层或定时任务中补位。触发器本身只做轻量、本地、确定性操作。
- 在应用代码中：执行完主表
INSERT/UPDATE后，立刻用同一事务连接去查/改db2.t—— 这是最常用也最可控的方式 - 用 MySQL 事件（
EVENT）+ 状态字段：在触发器里仅更新一个标记字段（如sync_flag TINYINT DEFAULT 0），再由每秒轮询的事件检查并同步到db2.t - 用外部消息队列（如 Kafka、RabbitMQ）解耦：触发器写入本地日志表，另一服务监听该表变更并投递到
db2.t - 避免用
FEDERATED引擎：虽然理论上可建指向其他库的代理表，但它在 8.0+ 已默认禁用、性能差、事务不一致风险高，生产环境基本不用
为什么有人试 SELECT * FROM db2.t 在触发器里“好像没报错”？
那大概率是用了 BEFORE INSERT 并只读（SELECT），且目标表恰好存在、用户有权限——但这只是“侥幸通过语法检查”，实际执行时仍可能因事务隔离或锁机制失败；更危险的是，这种写法在 MySQL 5.7 下可能静默跳过，到 8.0 直接拒绝。
-
BEFORE触发器中允许SELECT跨库，但仅限只读，且不能用于赋值给NEW.xxx（否则报错） -
AFTER触发器中连只读跨库SELECT都会被拒绝（报ERROR 1442） - 即便 SELECT 成功，也无法保证结果实时性：触发器执行时，
db2.t可能正被其他事务修改，且不可见未提交变更 - 一旦涉及
JOIN db2.t或子查询，几乎必然失败
如果非要在数据库内闭环，有没有折中设计？
有，但代价是增加维护复杂度和一致性风险。核心思路是“把跨库动作降级为本地操作”，靠人工保障最终一致。
- 在当前库建一张影子表（如
sync_to_db2_queue），触发器只往里插记录（含目标库表名、操作类型、关键字段值） - 用单独的存储过程定期扫描该队列表，用
PREPARE + EXECUTE拼接 SQL 去操作db2.t，失败则重试或记日志 - 务必加唯一索引（如
(src_id, op_type)）防重复同步；同时在db2.t加ON DUPLICATE KEY UPDATE容忍幂等 - 注意：这种方案无法回滚跨库操作，若主库事务回滚，队列表已写入，需额外补偿逻辑
跨库这件事，MySQL 就没打算让触发器扛。别硬刚语法，把边界划清楚——触发器管好本库状态，其他交给应用或调度，反而更稳。
