MySQL跨库触发器合法但风险高，需严格对齐引擎（全InnoDB）、权限（DEFINER）和事务边界；语法须显式带库名，仅AFTER触发器安全，禁止USE、INSERT IGNORE、跨库函数调用及会话变量控制。
MySQL触发器可以跨库操作，但「能写」不等于「能稳」——跨库写入本身合法，而数据一致性完全取决于引擎、权限、事务边界这三者的实际对齐情况，缺一不可。
跨库语法必须显式带库名，且仅限DML
触发器里所有对非当前库表的操作，都得写成 db_name.table_name。比如在 sales.orders 上建触发器，想往 audit.log 写日志，就得写 INSERT INTO audit.log；不写 audit. 就默认去 sales.log 找表，大概率报 ERROR 1146 (42S02): Table 'sales.log' doesn't exist。
OLD 和 NEW 只能引用本表字段，不能直接跨库取值（如 SELECT name FROM user_db.users WHERE id = NEW.user_id 是非法的）。真要查其他库的数据做判断，得先用 SELECT ... INTO @var 赋值，再参与后续逻辑。
- 禁止在触发器里执行
USE other_db—— 该语句在触发器中直接报错 -
INSERT IGNORE和REPLACE INTO不触发任何触发器，跨库同步逻辑会彻底丢失 - 视图可以跨库查，但必须显式写成
SELECT * FROM other_db.vw_name，且基础表权限必须全部满足
事务一致性只在全InnoDB时成立
跨库 DML 语句和主语句共享同一个事务上下文，只要所有涉及的表都是 InnoDB 引擎，任意一步失败（如唯一键冲突、磁盘满），整个操作包括跨库那条都会回滚。
但只要有一张 MyISAM 表参与（哪怕只是日志表），原子性就失效：InnoDB 部分可撤，MyISAM 部分会提前落盘、无法撤销。上线前务必检查：SHOW CREATE TABLE other_db.t 确认引擎。
- FEDERATED 表更危险：网络超时或远程库不可用时，可能触发隐式
COMMIT，直接违反事务约束，报ERROR 1422 - 避免在触发器中调用含跨库操作的函数，特别是声明为
READS SQL DATA或MODIFIES SQL DATA的函数，会直接被 MySQL 拒绝（ERROR 1419） - 高并发下，跨库
UPDATE容易扩大锁范围，比如订单表触发器去扣库存，可能阻塞其他订单处理
权限检查走 DEFINER，不是调用者
触发器执行时，权限检查依据的是 DEFINER 用户（创建者），不是执行原始语句的账号。哪怕你用 root 插入数据，触发器内部写 report.monthly_summary，也只看 DEFINER 是否有 INSERT ON report.monthly_summary 权限。
没权限不会报具体权限错误，而是整个原始语句失败，常见报错是 ERROR 1142 (42000): INSERT command denied to user。用 SHOW CREATE TRIGGER trigger_name 可确认 DEFINER 是谁；建触发器前，先用该账号手动执行一遍目标语句，确保通得过。
- DEFINER 权限不足时，错误常静默，容易误判为逻辑问题而非权限问题
- 跨库操作若涉及存储过程，过程内仍不能执行
COMMIT或START TRANSACTION，否则触发器报错 - 不要依赖
@disable_trigger这类会话变量控制跨库行为——主从复制中从库 SQL 线程会话独立，该变量始终为NULL，必然导致循环
AFTER INSERT 是唯一安全的跨表同步时机
BEFORE INSERT 里 NEW.id 是 NULL，没法往目标表插主键关联数据；只有 AFTER INSERT 才能确保自增 ID、默认值、NOW() 等全部就绪。错误写法：BEFORE INSERT 中 INSERT INTO log_table (user_id) VALUES (NEW.id) → 插入失败。
跨表同步必须用单值子查询，且带 LIMIT 1，例如：SET NEW.sync_status = (SELECT IF(t2.is_valid = 1,'ok','error') FROM config t2 WHERE t2.key_name = NEW.config_key LIMIT 1)。多行返回直接让触发器失败。
- 目标表字段类型必须严格匹配源表，隐式转换可能导致截断（如
BIGINT UNSIGNED→INT） - 禁止在
AFTER触发器里写SET NEW.xxx =—— 直接报ERROR 1362 - DELETE 触发器依赖
OLD，但目标表若有外键或唯一索引冲突，整个删除会回滚；更麻烦的是，INSERT IGNORE对跳过的行完全不触发任何触发器
真正容易被忽略的点是：跨库操作的“一致性”不是靠触发器保证的，而是靠你亲手确认每张表的引擎、每个用户的权限、每条语句的事务边界是否严丝合缝。一旦其中任一环松动，触发器只会把问题藏得更深。
