mysqldump 默认不导出 EVENTS，必须显式加 --events；还需配合 --routines 和 --triggers 确保依赖逻辑完整，并注意 --skip-definer 和 --set-gtid-purged=OFF 等关键参数。
mysqldump 默认不导出 EVENTS，必须显式加 --events
mysql 的 mysqldump 默认只导出表结构、数据和存储过程，event 对象（即事件调度器里的定时任务）完全被忽略。如果你备份完恢复，发现所有 create event 语句都没了，八成是漏了这个参数。
实操建议：
- 加
--events是硬性要求，不加就等于没备份事件 - 它必须和
--routines（存储过程/函数）分开指定，不能合并成一个开关 - 如果用
--all-databases，--events依然有效，但只对当前有EVENT权限的库生效 - 注意权限：执行用户需有
EVENT权限，否则即使加了参数也会静默跳过，不报错也不导出
导出时要不要加 --triggers 和 --routines？要看实际依赖
很多自动化任务不止靠 EVENT，还会在触发器（TRIGGER）或存储过程（ROUTINE）里调用逻辑。比如一个每日清理事件，可能调用 CALL clean_old_logs() —— 如果只导 EVENT，没导 clean_old_logs 这个存储过程，恢复后事件会直接报 PROCEDURE not found。
判断依据：
- 查
SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.EVENTS，再看对应库下有没有关联的ROUTINES或TRIGGERS - 如果不确定，保险起见加上
--triggers --routines，三者组合才完整 -
--triggers默认开启（只要没显式关），但--routines和--events都默认关闭，别凭印象猜
恢复时 DEFINER 权限问题常导致事件无法启用
导出的 CREATE EVENT 语句里带 DEFINER='user'@'host'。恢复时如果目标库没有这个用户，或者该用户没 EVENT 权限，事件会被创建但处于 DISABLED 状态，且 SHOW EVENTS 里 Status 显示 SLAVESIDE_DISABLED 或直接不显示。
解决办法：
- 导出前用
mysqldump --events --skip-definer去掉DEFINER，让恢复时自动设为当前用户（前提是当前用户有EVENT权限） - 或手动替换 dump 文件里的
DEFINER行（用sed -i 's/DEFINER=`.*`@`.*`//'），但要注意别误伤其他语句 - 恢复后检查：
SELECT EVENT_NAME, STATUS FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'your_db';，状态不是ENABLED就得排查权限
备份脚本里容易漏掉 --set-gtid-purged=OFF（尤其在 GTID 模式下）
如果 MySQL 开了 GTID（gtid_mode=ON），默认 mysqldump 会在 dump 头部写 SET @@GLOBAL.GTID_PURGED。这会导致恢复时报错 Cannot add or update a child row: a foreign key constraint fails 或直接拒绝导入，因为 GTID 集合冲突。
正确做法：
- 加
--set-gtid-purged=OFF，避免写入 GTID 信息（适用于非主从同步场景的纯备份恢复） - 如果备份用于搭建从库，那就得保留 GTID，此时要用
--set-gtid-purged=AUTO并确保主从位点一致 - 这个参数和
--events无关，但常一起出现在生产备份脚本里，漏掉一个就可能让整个恢复流程卡住
