mysqldump 导出时默认禁用触发器，需显式加--triggers参数；导入时需处理definer不存在、同名冲突、函数弃用、依赖顺序等问题，跨版本迁移尤需验证触发逻辑实效性。
mysqldump 导出时触发器被自动禁用
MySQL 5.7+ 默认在 mysqldump 中加上 --skip-triggers 行为（即使你没写），导致导出的 SQL 文件里没有 CREATE TRIGGER 语句。迁移后触发器直接消失，业务逻辑就断了。
实操建议：
- 导出时显式加
--triggers参数，例如：mysqldump --triggers -u root -p db_name > backup.sql - 检查导出文件是否真含
CREATE TRIGGER：用grep -n "CREATE TRIGGER" backup.sql - 如果目标库是 MySQL 8.0+，注意
DEFINER用户可能不存在，导入会报错ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist
导入时触发器名重复导致 ERROR 1359
目标库已有同名触发器，而 dump 文件又执行一遍 CREATE TRIGGER，就会触发 ERROR 1359 (HY000): Trigger already exists —— 这不是语法错，是严格模式下的拒绝行为。
实操建议：
- 别依赖
DROP DATABASE后重建：有些触发器绑定在系统表或跨库视图上，删库不等于清干净 - 导入前手动清理：运行
SELECT CONCAT('DROP TRIGGER ', TRIGGER_NAME, ';') FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'db_name';生成删除语句 - 或者改用
CREATE OR REPLACE TRIGGER？不行，MySQL 不支持该语法，必须先删后建
触发器中引用的表或函数在新版本不可用
比如旧库用 OLD.col_name 引用一个被重命名的字段，或用了已废弃的 ENCRYPT() 函数，导入时不会报错，但触发器创建成功却在运行时报 ERROR 1362 (HY000) 或静默失效。
实操建议：
- 在目标库提前执行
SHOW CREATE TRIGGER trigger_name，比对字段名、函数、权限上下文是否一致 - 特别注意 MySQL 8.0 的默认认证插件变更：如果触发器里调用
USER()或涉及 DEFINER，可能因插件不兼容拿不到预期用户名 - 测试阶段务必用真实 DML 操作验证触发逻辑，不能只看创建成功
备份时没处理触发器依赖顺序
触发器之间有执行依赖（比如 A 触发器更新表 X，B 触发器监听表 X），但 mysqldump 按字母序输出触发器，可能导致导入后顺序错乱、逻辑覆盖或死锁。
实操建议：
-
mysqldump本身不保证触发器执行顺序，必须人工干预 - 从
information_schema.TRIGGERS查出所有触发器，按EVENT_OBJECT_TABLE和ACTION_TIMING分组排序，手动生成重建脚本 - 复杂场景下，干脆放弃全量导入，改用
SELECT ... INTO OUTFILE+ 手动补触发器逻辑，可控性更高
真正麻烦的不是“怎么重建”，而是“重建之后它到底有没有按你想象的方式跑”。尤其跨大版本（如 5.6 → 8.0）时，DEFINER、SQL SECURITY、字符集隐式转换这几个点，一漏就查半天。
