迁移后触发器执行失败主因是DEFINER用户在新环境不存在或权限不足；需先查SHOW CREATE TRIGGER确认DEFINER，再验证用户存在性及对应表、过程、系统变量权限；MySQL 8.0+还需SYSTEM_VARIABLES_ADMIN；修复须导出→替换DEFINER→删除→重建，禁用直接改mysql.triggers；SQL SECURITY INVOKER慎用，推荐统一设为专用运维账号。
迁移后触发器执行失败，大概率是 DEFINER 用户在新环境不存在，或该用户没被授予触发器内 SQL 所需的权限 —— 不是创建者没权限，而是定义者“身份”失效了。
查触发器当前的 DEFINER 是谁
先确认问题源头，别猜。直接查：
SHOW CREATE TRIGGER trigger_name;
重点关注输出里类似 DEFINER=`old_user`@`%` 这一行。再验证这个用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'old_user';
如果查不到，说明用户确实丢了；如果存在，继续查它有没有触发器里操作的表权限：
SHOW GRANTS FOR 'old_user'@'%';
- 触发器里写了
INSERT INTO log_db.audit_log？那old_user就得有log_db.audit_log的INSERT权限 - 触发器里调用了存储过程？那个过程的
DEFINER也得存在且有对应权限（嵌套校验） - MySQL 8.0+ 还要额外检查是否授予了
SYSTEM_VARIABLES_ADMIN（尤其当触发器读取系统变量时）
批量修改触发器 DEFINER 的安全做法
不能直接改 information_schema.TRIGGERS（它是只读视图），必须走导出 → 替换 → 删除 → 重建流程：
- 用
mysqldump导出触发器（不带表结构和数据）：mysqldump -u root -p --triggers --no-create-info --no-data --skip-opt dbname > triggers.sql - 用
sed或编辑器全局替换DEFINER=`old_user`@`%`为DEFINER=`new_user`@`%`（推荐用当前有足够权限的运维账号，比如'admin'@'%'） - 执行前先删旧触发器（避免重复定义报错）：
DROP TRIGGER IF EXISTS trigger_name; - 导入修改后的文件：
mysql -u root -p dbname < triggers.sql
注意：如果触发器里含函数或过程调用，确保 new_user 对那些对象也有执行权限，否则重建后仍会执行失败。
为什么不能只改 mysql.triggers 表？
MySQL 5.7+ 的 mysql.triggers 表是只读的，写入会报错 ERROR 1294 (HY000): Invalid or non-existent trigger definition。硬改底层表不仅无效，还可能破坏元数据一致性。官方明确不支持这种操作，连 UPDATE mysql.triggers SET definer=... 都会被拒绝。
另外，有些云数据库（如阿里云 RDS、腾讯云 CDB）直接禁用对 mysql 系统库的写权限，试图绕过导出重建流程只会卡在第一步。
临时绕过方案：SQL SECURITY INVOKER 要慎用
如果你确认所有触发器内的语句对「调用者」都已授权（比如应用用户本身就有 INSERT 到日志表的权限），可以考虑重建时加上 SQL SECURITY INVOKER：
CREATE TRIGGER ... SQL SECURITY INVOKER BEFORE INSERT ON t1 ...
但要注意：
- 这会让触发器以执行
INSERT的用户身份运行，权限模型彻底变了 —— 原来靠DEFINER隐藏的权限边界消失了 - 如果多个应用用户权限不一致，同一触发器可能在 A 用户下成功、B 用户下失败
- 无法解决跨库写入问题（比如触发器要往
syslog库写，但应用用户根本没被授过那个库的权限）
真正省事又安全的做法，还是统一把 DEFINER 改成一个长期维护的、权限收口的专用账号，并确保它在所有目标实例中存在且权限完整。
