不加--events参数，mysqldump完全不会导出任何事件（即无CREATE EVENT语句）；必须显式指定--events且执行用户具备EVENT权限，才能导出事件，否则静默跳过。
不加 --events，mysqldump 就不会导出任何事件——不是“可能漏”，是根本不会生成 create event 语句。
必须显式启用 --events 才能导出事件
mysqldump 默认行为只处理表、视图、存储过程（--routines 需手动开）、触发器（--triggers 默认开），但 EVENT 对象完全被跳过。哪怕你用了 --all-databases 或指定了具体库名，没加这个参数就等于备份里没有事件。
- 执行用户必须有
EVENT权限，否则即使加了--events也会静默跳过，不报错也不写入 dump 文件 -
--events和--routines是独立开关，不能合并；--triggers虽默认开启，但若显式关了（如--skip-triggers）就得再打开 - 如果事件调用存储过程（比如
CALL cleanup_logs()），只导--events不导--routines，恢复后事件会直接报PROCEDURE not found
避免 DEFINER 导致事件创建后 DISABLED
导出的 CREATE EVENT 语句默认带 DEFINER='user'@'host'。目标库若不存在该用户，或该用户没 EVENT 权限，事件会被创建但状态为 SLAVESIDE_DISABLED，SHOW EVENTS 里看不到或显示 DISABLED。
- 最稳妥：导出时加
--skip-definer，让mysqldump去掉DEFINER子句，恢复时自动以当前登录用户为执行者（前提是该用户有EVENT权限） - 不推荐 sed 替换整个 dump 文件里的
DEFINER，容易误伤其他语句（比如函数或视图里也有DEFINER） - 别指望
SQL SECURITY DEFINER自动绕过权限——它不会帮你建用户，也不会提升权限
GTID 环境下要加 --set-gtid-purged=OFF
如果源库启用了 GTID（gtid_mode=ON），mysqldump 默认会在 dump 文件头部插入 SET @@GLOBAL.GTID_PURGED = '...'。在目标库导入时，若该 GTID 集合与目标库已有事务冲突，会直接报错中断导入。
- 跨实例迁移、尤其是从主库导出到测试库或灾备库时，必须加
--set-gtid-purged=OFF - 这个参数和
--events无依赖关系，但常一起出现；漏掉它，dump 文件可能根本无法导入 - 若目标库也开 GTID 且需保持复制一致性，应改用
--set-gtid-purged=ON并确保源库已执行完所有事务
恢复前必须确认 event_scheduler 已启用
导出再完整，目标库没开调度器，事件照样不执行。而且这个开关不会随 dump 文件自动生效，必须手动设置。
- 导入前执行：
SET GLOBAL event_scheduler = ON; - 仅执行一次不够——MySQL 重启后会重置，建议写进
my.cnf：event_scheduler=ON - 验证是否真开了：
SHOW VARIABLES LIKE 'event_scheduler';返回值必须是ON，不是ENABLED或空值 - 导入后立即检查：
SHOW EVENTS FROM your_db;，注意看Status列是否为ENABLED
最容易被忽略的是权限链：导出时用户要有 EVENT 权限，导入时用户也要有 EVENT 权限，且目标库对应数据库对象（表、过程等）的读写权限也得提前配好——缺一环，事件就卡在“存在但不运行”状态。
