先确认event_scheduler实际状态是否为DISABLED，再检查配置文件路径、事件ENABLE状态、EVENT权限及系统变量权限。
event_scheduler 显示 ON 但事件不执行？先确认是不是 DISABLED
看到 SHOW VARIABLES LIKE 'event_scheduler' 返回 ON，不代表真能跑——它可能只是“表面 ON”，实际状态是 DISABLED。这个三态（ON/OFF/DISABLED）里，DISABLED 是最狠的：连 SET GLOBAL event_scheduler = ON 都会被拒绝，报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option 或静默失败。
真正判断方式是：
- 执行
SELECT @@event_scheduler;—— 返回DISABLED就坐实了 - 查错误日志，找
Unknown system variable 'event_scheduler'（说明版本太低，但迁移通常不会降级）或skip-event-scheduler字样 - 检查配置文件是否被托管服务（如阿里云 RDS、腾讯云 CVM）屏蔽：RDS 根本不让你改
my.cnf，必须走控制台「参数设置」提交event_scheduler = ON
迁移后 my.cnf 没生效？别只改一个路径
自建 MySQL 迁移常踩坑：你改了 /etc/my.cnf，但 MySQL 实际加载的是 /etc/mysql/mysql.conf.d/mysqld.cnf，或者 Windows 下是 C:\ProgramData\MySQL\MySQL Server X.X\my.ini 而非安装目录下的 my.ini。
确认真实加载路径的唯一可靠方法：
- Linux：运行
mysqld --verbose --help 2>&1 | grep "Default options"，看第一行输出的配置路径 - Windows：命令行执行
mysqld --verbose --help | findstr "Default options" - 如果返回空，说明 MySQL 正在用编译默认值启动——此时
event_scheduler必定是DISABLED，必须显式提供配置文件
在正确配置文件的 [mysqld] 段下写：
event_scheduler = ON
注意：event_schduler（少个 e）、# event_scheduler = ON（被注释）、或存在 skip-event-scheduler 行，都会导致失效。
事件本身是 DISABLE 状态？创建时没加 ENABLE
即使调度器开了，单个事件默认也是禁用的。执行 SHOW EVENTS 查看 Status 列，如果显示 DISABLED，说明事件没激活。
创建事件时必须显式声明 ENABLE：
CREATE EVENT test_event ON SCHEDULE EVERY 30 SECOND ENABLE -- 关键！不能省 DO INSERT INTO test_log VALUES (NOW());
已有事件可手动启用：
ALTER EVENT event_name ENABLE;- 或重建时加
ENABLE，避免用IF NOT EXISTS隐蔽覆盖旧定义
注意：事件作用域是数据库级的，跨库调用表时权限由调用者决定，不是定义者——如果事件里写了 INSERT INTO other_db.table，当前用户得有那个库的写权限。
迁移后权限丢了？EVENT 权限不是自动继承的
事件创建者必须拥有 EVENT 权限，且该权限不会随数据库 dump 自动带过去。迁移后常见情况是：用户账号存在，但没授 EVENT。
验证方式：
-
SHOW GRANTS FOR 'your_user'@'host';—— 看输出里有没有GRANT EVENT ON *.* - 没有就补：
GRANT EVENT ON *.* TO 'your_user'@'host'; FLUSH PRIVILEGES;
特别注意：MySQL 8.0+ 对 EVENT 权限要求更严，如果事件体里读取了系统变量（比如 @@max_connections），还得额外授予 SYSTEM_VARIABLES_ADMIN。
最后提醒一句：event_scheduler 和普通连接共享线程资源，高并发事件可能因 max_connections 耗尽而静默失败——查 SHOW PROCESSLIST 里有没有大量 Daemon 类型线程卡住，比等日志报错更早发现问题。
