触发器和存储过程迁移后“消失”是因为mysqldump默认不导出它们，必须显式添加--triggers和--routines参数；仅加其一或遗漏任一均导致对应对象缺失，且导入时因definer用户缺失、权限不足或event_scheduler=on等原因可能静默失败。
触发器和存储过程在迁移后“消失”，不是备份失败，而是 mysqldump 默认根本不会导出它们——除非你显式告诉它要导。
导出时漏了 --triggers 和 --routines 参数
这是最常见、也最容易被忽略的根源。默认情况下，mysqldump 只导表结构、数据和视图，--triggers 和 --routines 是两个独立开关，缺一不可：
-
--triggers：只导触发器（含DEFINER），不导存储过程 -
--routines：导存储过程（PROCEDURE）和函数（FUNCTION），不导触发器 - 用
--databases或-B时，--triggers不会自动启用，必须手写
正确命令示例：mysqldump -u root -p --triggers --routines --databases mydb > backup.sql
验证备份文件是否真包含：打开 backup.sql，搜索 CREATE TRIGGER 或 CREATE PROCEDURE —— 如果没结果，说明参数确实漏了。
导入时因 DEFINER 用户缺失或权限不足静默失败
即使导出了，导入时也可能“看似成功，实则跳过”。因为 CREATE TRIGGER 语句里带 DEFINER=`old_user`@`%`，而目标库没有这个用户，或该用户没授对应权限：
- 先查定义者：
SHOW CREATE TRIGGER trigger_name;，看DEFINER字段 - 再查用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'old_user'; - 若不存在，建用户并授权：
CREATE USER 'old_user'@'%' IDENTIFIED BY 'pwd'; GRANT TRIGGER, EXECUTE ON mydb.* TO 'old_user'@'%'; - MySQL 8.0+ 还需额外权限：
SYSTEM_VARIABLES_ADMIN（如果触发器读取@@version等变量）
注意：mysqldump 导入时遇到权限不足，常不报错，而是直接跳过创建语句——所以不能只看“无报错”就认为成功。
跨版本迁移时语法或 sql_mode 不兼容
MySQL 5.7 和 8.0 对触发器/存储过程的校验更严格，容易在导入时卡住：
- MySQL 8.0 默认开启
STRICT_TRANS_TABLES，触发器内插入超长字符串会直接报错中断；5.7 可能仅警告 - 使用
UUID()或NOW()的存储过程，在binlog_format=STATEMENT下，8.0 要求显式声明DETERMINISTIC，否则CREATE PROCEDURE失败 - 触发器中写的表名带库前缀（如
mydb.users），目标库名若不一致，会报Table doesn't exist
建议迁移前先在目标版本执行：SHOW CREATE TRIGGER trigger_name;，复制语句到新库的 MySQL 客户端里试运行，提前暴露语法问题。
event_scheduler = ON 导致 mysqldump 输出非法 SQL
这是个隐蔽但致命的问题：当原库 event_scheduler 被设为 ON（比如有人手动执行过 SET GLOBAL event_scheduler = ON;），mysqldump 会在输出中混入事件（EVENT）定义，其中可能含时间逻辑错误（如 ENDS 在 STARTS 之前），导致整个 SQL 文件导入失败，报错类似：ERROR 1543 (HY000): ENDS is either invalid or before STARTS。
解决办法很直接：
- 迁移前检查：
SELECT @@event_scheduler; - 若为
ON，临时关闭：SET GLOBAL event_scheduler = OFF; - 再执行
mysqldump，导出后可重新开启
这个参数状态不会随备份持久化，但它会影响 dump 过程本身——很多人查了半天权限和语法，最后发现是它在作祟。
真正麻烦的不是导不出，而是导出后导入失败却不报错；最易被忽略的不是参数，而是 event_scheduler 这种“看起来和触发器无关”的全局变量。
