phpMyAdmin导出事件必须手动勾选“Events”选项、确保用户具备EVENT权限、并配合“Add DROP...EVENT statement”选项，否则导出文件中不会包含CREATE EVENT语句；命令行需显式添加--events参数，且DEFINER不匹配会导致恢复后事件无法启用。
phpmyadmin 本身不提供独立的“导出事件”功能按钮，事件（event）必须随数据库整体导出，且需满足三个硬性条件：导出时勾选 events、用户具备 event 权限、mysqldump 或 phpmyadmin 的导出逻辑实际包含该对象。否则导出文件里根本不会出现 create event 语句。
phpMyAdmin 导出页面必须手动勾选 Events
很多人点开“导出”→“Custom”，却只关注表和数据，忽略底部“对象（Objects）”区域——Events 默认不勾选，且没有视觉提示它被禁用。不主动打钩，就等于没备份。
- 进入 Custom 导出模式后，向下滚动到「对象」区块
- 必须手动勾选
Events（旁边还有Views、Stored procedures等，一并检查） - 同时勾选
Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT statement，否则恢复时事件可能因重复定义失败 - 如果导出后打开 .sql 文件搜索
CREATE EVENT没结果，基本就是这里漏了
mysqldump 命令行导出事件必须加 --events 参数
phpMyAdmin 底层调用 mysqldump，但界面隐藏了参数控制。一旦导出失败或内容缺失，直接上命令行更可控。不加 --events，哪怕你有权限、调度器开着，dump 里也绝对没有事件。
mysqldump -u root -p --events --routines --triggers mydb > mydb_full.sql-
--events和--routines是两个独立开关，不能合并；--triggers默认开启，但显式加上更稳妥 - 若目标库用户无
EVENT权限，--events会静默跳过，不报错也不写入，务必先确认权限：SHOW GRANTS FOR CURRENT_USER; - 导出后立刻验证：
grep -i "create event" mydb_full.sql | head -3
导出后事件无法启用？大概率是 DEFINER 权限不匹配
导出的 CREATE EVENT 语句自带 DEFINER='user'@'host'，恢复时若该用户不存在或无 EVENT 权限，事件会被创建但状态为 SLAVESIDE_DISABLED 或直接不可见。
- 最安全做法：导出时加
--skip-definer（命令行），让恢复时自动设为当前执行用户 - phpMyAdmin 界面无法跳过 DEFINER，只能事后处理：用
sed -i 's/DEFINER=`[^`]*`@`[^`]*`//g' backup.sql批量清理（注意别误删其他 DEFINER） - 恢复后必查：
SELECT EVENT_NAME, STATUS, DEFINER FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'mydb';，状态不是ENABLED就得回溯权限
真正容易被忽略的不是操作步骤，而是权限与 DEFINER 的耦合关系：你导出了事件，不代表它能在新环境跑起来。每次导出后，都要把 SHOW GRANTS 结果和 information_schema.EVENTS 状态一起存档，才算完整闭环。
立即学习“PHP免费学习笔记（深入）”；
