mysql触发器支持跨库操作，需显式写全库名表名；不支持在触发器中修改被触发表；权限以definer为准；单表最多6个触发器；所有触发器随主事务回滚，不可自主启停事务。

能跨库，但必须写全库名表名

MySQL触发器完全支持跨库操作，只要你在语句里明确写出 db_name.table_name。它不是靠当前 USE 的库生效，而是靠你写的完整路径——比如在 sales 库的订单表上建触发器，想往 audit_db.audit_log 插日志，直接写 INSERT INTO audit_db.audit_log (...) VALUES (...) 就行。

• 不写库名就默认操作当前库，跨库时漏写会插错地方甚至报错表不存在
• 视图也能跨库查，但得满足两个条件：视图本身可访问 + 触发器里显式写成 SELECT * FROM other_db.vw_name
• 函数调用要小心：get_user_count(other_db.users) 这种如果声明为 READS SQL DATA，在触发器里直接调会失败；更稳妥是改用存储过程 + CALL，但注意不能在其中执行 COMMIT

ERROR 1442 不是跨库问题，是动了本表

这个错误码常被误读为“不能跨表/不能跨库”，其实它只拦一件事：在触发器里对「正在被触发的那张表」做任何 DML 操作（包括 SELECT COUNT(*) 这种只读查询，在某些版本也会触发）。

• 错误示例：在 OperationLog 的 AFTER INSERT 触发器里写 DELETE FROM OperationLog LIMIT 1
• 正确替代：把日志写到另一张表（如 operation_log_archive），或把清理逻辑移到应用层、定时 EVENT 中执行
• 哪怕只是想查本表判断状态，也建议改用 NEW 或 OLD 字段值做逻辑分支，避免碰表

跨库权限、事务和隐性依赖这三关最容易翻车

语法通了不代表线上能跑稳。真正出问题的地方往往藏在权限配置、引擎一致性、以及业务代码根本没意识到的“幽灵路径”里。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 权限陷阱：触发器以 DEFINER 身份运行，不是调用者。比如定义者是 'root'@'localhost'，但业务账号没给 log_db.log_table 的 INSERT 权限，就会静默失败
• 事务一致性：只要目标库也是 InnoDB，跨库操作仍包在原事务中，失败会一起回滚；但只要有一张 MyISAM 表参与，原子性就没了——InnoDB 部分可撤，MyISAM 部分会提前落盘，无法撤销
• 不可见性风险：业务代码没碰 config_db.default_settings，但某张表的触发器悄悄改了它。查 Bug 时没人想到这条路径，排查周期拉长好几天

单表最多6个触发器，命名全局唯一

一个表最多只能有6个触发器：每个事件（INSERT/UPDATE/DELETE）各配一个 BEFORE 和一个 AFTER。超了会报 ERROR 1235 (42000)，而不是“已存在”那种提示。

• 触发器名作用域是整个数据库，不是表级。不能有两个触发器都叫 tr_log_after_insert，哪怕一个在 users、一个在 orders
• 建的时候必须显式命名，MySQL 不会自动生成；重命名也不支持，只能先 DROP TRIGGER IF EXISTS old_name 再重建
• 所有触发器都随主事务回滚，但不支持自己开事务（START TRANSACTION）、也不能执行 COMMIT 或 ROLLBACK

跨库触发器最麻烦的从来不是语法，而是你改了一行 SQL，却让三个库之间的权限、引擎、调用链同时暴露问题。上线前最好用实际账号连上去，手动跑一遍触发逻辑，别只信 root 账号下的测试结果。