迁移后触发器和存储过程无法执行，根本原因是DEFINER用户在新库不存在或权限不足；须用SHOW CREATE TRIGGER/PROCEDURE查定义者，SELECT验证用户存在性，SHOW GRANTS核验其对涉及库表及系统变量的权限，MySQL 8.0+还需SYSTEM_VARIABLES_ADMIN；导出需同时加--triggers和--routines，禁用直接改mysql.triggers，应导出→替换DEFINER为专用账号→DROP→重建。
迁移后触发器和存储过程无法执行，基本就是 DEFINER 用户在新库不存在，或该用户没被授予对应操作权限——不是“语法错了”，而是“身份失效了”。
查清楚当前触发器/存储过程的 DEFINER 是谁
别猜，直接查：
SHOW CREATE TRIGGER trigger_name; 或 SHOW CREATE PROCEDURE proc_name;
重点看输出里这一行：DEFINER=`old_user`@`%`。再验证这个用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'old_user';
- 查不到 → 用户确实丢了，得重建账号并授权
- 查到了 → 接着查权限：
SHOW GRANTS FOR 'old_user'@'%'; - 如果触发器里写了
INSERT INTO log.audit_log，那old_user就必须有log.audit_log的INSERT权限 - MySQL 8.0+ 还要额外检查是否授予了
SYSTEM_VARIABLES_ADMIN（尤其当触发器读取@@version这类系统变量时）
mysqldump 导出时漏了关键参数
默认不导触发器，也不导存储过程。只加 --triggers 或只加 --routines 都不行，必须两个都带上：
mysqldump -u root -p --triggers --routines --databases mydb > backup.sql
-
--triggers：导出所有触发器（含DEFINER） -
--routines：导出存储过程和函数（不含触发器） - 用
-B（即--databases）时，--triggers不会自动启用，必须显式写上 - 导入时若报
ERROR 1418或Access denied，大概率是DEFINER用户缺失或权限不足
不能直接改 mysql.triggers 表
有人想绕过重建流程，直接 UPDATE mysql.triggers SET definer=... —— 这条路走不通：
MySQL 5.7+ 的 mysql.triggers 是只读表，写入会立刻报错：ERROR 1294 (HY000): Invalid or non-existent trigger definition。
- 官方明确不支持修改系统元数据表
- 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用对
mysql库的写权限 - 正确做法是：导出 → 替换
DEFINER→DROP TRIGGER IF EXISTS→ 重建 - 替换时推荐用专用运维账号，比如
DEFINER=`admin`@`%`，而不是CURRENT_USER（后者在不同连接上下文里不稳定）
触发器执行时静默失败，根本看不到报错
触发器失败不会抛异常给客户端，往往只是“该做的事没发生”，比如时间字段没更新、日志表没写入。
- 先确认触发器是否真被调用了：
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'mydb'; - 检查 MySQL 错误日志（路径由
log_error配置项决定），里面可能有ERROR 1442（不能改被触发的表）、权限拒绝等线索 - 避免在触发器里调用含事务控制的函数（
START TRANSACTION、SELECT ... FOR UPDATE），MySQL 禁止这种嵌套 - 调试建议：把触发器逻辑复制成带参数的存储过程，手动传值运行，中间加
INSERT INTO debug_log记录状态（注意别写到正在被触发的表）
最易被忽略的一点：即使 DEFINER 存在且权限齐全，如果触发器内部调用了另一个存储过程，而那个过程的 DEFINER 在新库也不存在——整个链就断了。嵌套依赖必须逐层验证。
