MySQL事件调度器默认关闭，因安全设计需手动启用：SET GLOBAL event_scheduler=ON临时生效，或在配置文件中设event_scheduler=ON并重启/在RDS控制台提交参数持久化。
show variables like 'event_scheduler' 返回 OFF
迁移后 event_scheduler 参数默认是关闭的，哪怕源库开着，RDS 或新实例也不会自动继承这个配置。这不是 bug，是 MySQL 的安全默认行为——调度器线程不启动，所有 event 都会被静默忽略。
执行 show variables like 'event_scheduler' 后如果看到 Value 是 OFF，必须手动开启：
-
SET GLOBAL event_scheduler = ON可立即生效，但重启后失效（仅会话级临时） - 在 RDS 控制台「参数设置」里把
event_scheduler改为ON并提交，才能持久化（阿里云、腾讯云均需此操作） - 自建 MySQL 需检查
my.cnf是否漏配event_scheduler=ON，否则服务重启即退回到 OFF
show events 显示状态为 DISABLED
迁移工具（如 mysqldump + source、DTS）通常只导出 event 定义语句，但不会保留原始 STATUS。即使 dump 文件里有 ENABLE 关键字，导入时若目标库当前 event_scheduler=OFF，MySQL 会强制将 event 置为 DISABLED 状态，且不报错。
验证方式：
- 运行
show events，看Status列是否为DISABLED - 或查系统表：
SELECT EVENT_NAME, STATUS FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'your_db_name' - 启用单个事件：
ALTER EVENT your_event_name ENABLE - 批量启用（慎用）：
SELECT CONCAT('ALTER EVENT ', EVENT_NAME, ' ENABLE;') FROM information_schema.EVENTS WHERE STATUS = 'DISABLED' AND EVENT_SCHEMA = 'your_db_name';，复制结果再执行
information_schema.EVENTS 中 LAST_EXECUTED 为空或远早于当前时间
LAST_EXECUTED 字段是判断 event 是否真正在跑的最直接依据。如果它为 NULL 或时间戳停在迁移前，说明 event 从未在新环境成功触发过。
这时候不要只盯着语法，优先排查：
- 事件的
STARTS时间是否设在将来？比如STARTS '2026-05-15 00:00:00'，那迁移后五天内都不会动 - 事件类型是
ONE TIME还是RECURRING？前者只执行一次，迁移后若已过期就永远不会再触发 - 事件定义中用了
NOW()或CURRENT_TIMESTAMP作动态起点，但导入时刻 MySQL 时区与预期不符，导致STARTS被计算成过去时间（尤其跨时区迁移时）
event_scheduler=ON 但 show processlist 看不到 Event_Scheduler 线程
即使参数显示 ON，也得确认后台线程真起来了。运行 show processlist，正常应有一行类似：
Id: 3 User: event_scheduler Host: localhost db: NULL Command: Daemon Time: 12345 State: Waiting for next activation Info: NULL
如果没有这一行，常见原因：
- RDS 实例处于「基础版」或低配规格，部分厂商（如早期阿里云 RDS）对 event_scheduler 有资源限制，需升配或提工单开通
- MySQL 版本低于 5.1.6，event 功能不可用（但你用的是 5.7，排除）
- 实例刚开启
event_scheduler，线程启动有秒级延迟；等 10 秒再查processlist
真正容易被忽略的是：有些云厂商控制台显示参数已改为 ON，但底层未真正 reload，必须点「提交」并等待「参数生效中」状态结束才算落地。
