MySQL 5.6.10事件调度器开启但部分事件无法运行如何排查

已知前置条件：

• 数据库版本为MySQL 5.6.10，此前已有多个事件可正常运行
• 手动执行事件内的存储过程调用、插入语句均可正常运行
• 对异常事件执行禁用/启用、删除重建操作均无效，新建最简测试插入事件同样无法执行

测试事件创建语句参考：

CREATE EVENT test_event_01
    ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
    ON COMPLETION PRESERVE
    DO
    BEGIN
       INSERT INTO  test_db.test_event_msg(message_text,createdDate)
          VALUES('Test MySQL Event 1',UTC_TIMESTAMP());
    END 

排查方向与修复方案 #

• 确认事件调度器的真实运行状态
  不要仅依赖之前“已开启”的记忆，执行SHOW VARIABLES LIKE 'event_scheduler';确认返回值为ON；再执行SHOW PROCESSLIST;，确认列表中存在User为event_scheduler、Command为Daemon的后台常驻线程。如果该线程不存在，说明调度器实际未正常运行，执行SET GLOBAL event_scheduler = OFF;等待3秒后再执行SET GLOBAL event_scheduler = ON;即可重启调度线程。注意如果event_scheduler在数据库启动时被配置为DISABLED，无法在运行时动态开启，必须修改my.cnf配置后重启数据库生效。
• 校验事件本身的配置、定义者权限与完整性
  执行SELECT * FROM information_schema.EVENTS WHERE EVENT_NAME IN ('你的异常业务事件名','test_event_01')\G重点核对几个字段：
  • STATUS字段值必须为ENABLED，如果实例是主从架构的从库，SLAVESIDE_DISABLED状态的事件不会在从库执行
  • DEFINER字段对应的数据库账号必须真实存在，且具备事件逻辑需要的所有权限：比如测试事件需要test_event_msg表的INSERT权限，业务事件需要对应存储过程的EXECUTE权限，账号不存在、权限被回收都会导致事件静默执行失败，这也是手动执行语句正常、事件执行失败的最常见原因
  • 核对EVENT_DEFINITION字段内容和预期逻辑是否一致，创建事件时未提前修改命令分隔符（delimiter），会导致BEGIN...END块内的分号提前截断SQL，实际创建的事件逻辑残缺
  • 查看LAST_EXECUTED字段是否始终为NULL，确认事件从未被调度触发
• 查看MySQL错误日志定位具体报错
  事件执行失败的报错默认不会返回到客户端，全部记录在MySQL数据目录下的.err后缀错误日志中，直接搜索事件预计执行时间点附近的日志内容，常见报错包括：定义者权限不足、SQL_MODE不兼容导致语句执行报错、元数据锁阻塞、磁盘空间不足无法写入、表损坏等。
• 排查时区与时间偏差问题
  执行SELECT NOW(),CURRENT_TIMESTAMP,UTC_TIMESTAMP();对比数据库当前时间和实际系统时间是否一致，再执行SHOW VARIABLES LIKE '%time_zone%';检查全局、会话时区配置。如果数据库时间和实际时间存在较大偏差，感知上的“到点未执行”实际是还没到达事件定义的执行时间，创建的一次性AT类型测试事件很容易因为时间偏差错过执行窗口。
• 核对复制场景的事件执行规则
  如果实例是主从复制架构中的从库，主库同步过来的事件默认会被设置为SLAVESIDE_DISABLED状态，不会在从库执行；如果是在从库本地创建的事件，需要确认创建时没有加DISABLE ON SLAVE属性，且从库本地的事件调度器处于开启状态。
• 规避MySQL 5.6.10版本的已知事件bug
  5.6.10是5.6系列的早期版本，存在多个已确认的事件调度相关bug：比如定义者用户名包含大写字符时事件无法被调度、调度线程异常退出后不会自动重启、lower_case_table_names参数变更后存量事件无法被识别。可以尝试显式指定DEFINER='root'@'localhost'重建测试事件，排除定义者解析问题；如果之前修改过大小写敏感配置，需要重建受影响的事件。

内容的提问来源于stack exchange，提问作者bill