MySQL迁移后触发器失效通常因导出工具默认不包含触发器，需用mysqldump加--triggers和--routines参数重新导出；缺失时可通过SHOW TRIGGERS或information_schema确认，再手动补录并注意DEFINER及依赖一致性。
MySQL迁移后触发器失效，通常不是“丢了”，而是没被自动复制过去——因为大多数导出工具（如mysqldump默认）不包含触发器，除非显式启用相关参数。
确认触发器是否真的缺失
登录目标库，执行：
SHOW TRIGGERS LIKE '表名';
或查系统表：
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = '数据库名';
如果结果为空，说明触发器确实未迁移成功。
导出时主动包含触发器
用mysqldump重
新导出，必须加这两个关键参数：
- --triggers：导出触发器定义
- --routines（可选但推荐）：同时导出存储过程和函数（若触发器依赖它们）
完整示例：
mysqldump -u用户 -p --triggers --routines --databases db_name > db_with_triggers.sql
手动补录触发器（应急方案）
如果原库还能访问，从源库提取触发器SQL：
SHOW CREATE TRIGGER trigger_name;
复制输出的 CREATE TRIGGER ... 语句，在目标库中直接执行。注意检查：
- 目标库是否存在同名触发器（先
DROP TRIGGER IF EXISTS） - 触发器引用的表、字段、函数在目标库中是否完全一致
- DEFINER 属性可能导致权限问题，可临时改为
DEFINER=CURRENT_USER或直接去掉（MySQL 8.0+ 默认行为已调整）
迁移后验证与预防
触发器逻辑常影响业务一致性（如自动更新时间、日志写入），迁移后务必验证：
- 对触发器关联的表做一次INSERT/UPDATE/DELETE操作
- 检查预期副作用是否发生（如时间字段更新、日志表是否有新记录）
后续迁移建议固化流程：把 --triggers --routines 写进备份脚本，避免遗漏。
