触发器迁移后“丢失”主因是mysqldump默认跳过导出（--skip-triggers），即使加-b或--all-databases也生效；导入时definer用户不存在导致error 1449静默失败；同名触发器冲突引发error 1359中断后续执行；存在但不执行可能是status=disabled、权限不足或事件不匹配。
触发器在迁移后“丢失”，绝大多数情况不是真的删了，而是根本没导出来——mysqldump 默认跳过触发器，连 CREATE TRIGGER 语句都没写进备份文件里。
mysqldump 默认不导出触发器
MySQL 5.7+ 版本起，mysqldump 默认启用 --skip-triggers 行为。哪怕你什么参数都没加，它也自动跳过触发器导出。
- 执行
mysqldump -u root -p mydb > backup.sql后，backup.sql里大概率没有一行CREATE TRIGGER -
--all-databases或-B（即--databases）都不自动包含触发器，仍受--skip-triggers影响 - 验证方法：运行
grep -n "CREATE TRIGGER" backup.sql，返回空就确认丢了
导入时 DEFINER 用户不存在导致“静默失败”
即使导出了触发器，导入时若 DEFINER 用户在目标库不存在，MySQL 会报 ERROR 1449，但很多工具（比如 mysql -f）会忽略该错误继续执行，结果是语句执行了、触发器却没建成功。
-
SHOW CREATE TRIGGER trigger_name查定义者，注意完整格式如DEFINER=`app_user`@`192.168.%` -
SELECT User, Host FROM mysql.user WHERE User = 'app_user'必须精确匹配 Host 部分，'app_user'@'%'≠'app_user'@'192.168.%' - 别急着建用户——用
sed -i "s/DEFINER=`[^`]*`@`[^`]*`/DEFINER=CURRENT_USER/g" backup.sql批量替换更安全高效
同名触发器冲突中断导入流程
MySQL 不支持 CREATE OR REPLACE TRIGGER。目标库已有同名触发器时，再次导入会卡在 ERROR 1359 (HY000): Trigger already exists，后续语句全被跳过。
- 不要依赖
DROP DATABASE清理——某些触发器绑定跨库对象或系统表，删库不等于清干净 - 导入前生成清理语句：
SELECT CONCAT('DROP TRIGGER ', TRIGGER_NAME, ';') FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb'; - 执行完这些
DROP TRIGGER再导入，避免顺序错乱或残留干扰
触发器存在但不执行，其实是“假存在”
触发器出现在 information_schema.TRIGGERS 里，不代表它能运行。常见假象包括：STATUS 字段为 DISABLED、DEFINER 权限不足、或触发事件不匹配实际操作（比如用 REPLACE INTO 却写了 BEFORE INSERT）。
- 查状态：
SELECT TRIGGER_NAME, STATUS FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';，必须是ENABLED - 查权限：
SHOW GRANTS FOR 'definer_user'@'host';，确保对触发器内所有表有对应 DML 权限（如日志表的INSERT） - 验证是否真触发：在触发器开头加一句
INSERT INTO debug_log VALUES (NOW(), 'fired');，看日志表有没有记录
真正容易被忽略的是嵌套依赖：触发器调用了存储过程，那个过程又有自己的 DEFINER；或者多个触发器监听同一张表，导入顺序错乱导致逻辑覆盖。这些不会报错，但行为已偏离预期。
