MySQL 事件调度器为什么没执行：event_scheduler、时区与重复触发核对

凌晨的清理任务明明在库里能查到，业务表却一行没少。先别急着改 ON SCHEDULE：MySQL 事件“不执行”至少可能是全局 event_scheduler 没开、事件自身被禁用、创建时区和预期不同，或者事件确实启动了但执行体报错。

先做一个能复查的清理事件

为了把“调度没启动”和“SQL 本身失败”分开，准备一个测试表和每分钟写入一条心跳的事件。生产环境不要直接照搬一分钟频率，示例只是为了缩短验证周期。

CREATE DATABASE IF NOT EXISTS event_lab;
USE event_lab;

CREATE TABLE event_heartbeat (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  fired_at DATETIME NOT NULL
);

CREATE EVENT ev_heartbeat
  ON SCHEDULE EVERY 1 MINUTE
  STARTS CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
  ON COMPLETION PRESERVE
  ENABLE
  DO INSERT INTO event_heartbeat(fired_at) VALUES (NOW());

ON COMPLETION PRESERVE 让事件定义在执行后继续保留，便于查看；一次性事件如果不保留，执行完可能从事件列表消失，排查时容易误以为创建失败。

第一步：确认服务器真的在接管事件队列

先查全局变量，不要只查自己的 session 变量：

SELECT @@global.event_scheduler AS scheduler_state,
       @@session.time_zone AS session_zone,
       @@global.time_zone AS global_zone;

只有 ON 才表示调度器启用。OFF 时事件可以存在，也可以被 SHOW EVENTS 查到，但不会按计划执行。启用全局变量需要足够的系统变量权限，不能把这一步偷偷塞进应用连接初始化里。

如果环境允许 DBA 操作，可在变更窗口执行：

SET GLOBAL event_scheduler = ON;

然后再次查询状态，并观察心跳表是否出现新行。这里的成功状态是“状态为 ON 且事件产生了新记录”，不是只看到 SET 语句返回成功。

第二步：检查事件自身的状态和下一次时间

全局开关正常后，再看事件对象。下面这条查询把最容易遗漏的字段放在同一行：

SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, EVENT_TYPE,
       TIME_ZONE, STARTS, ENDS, LAST_EXECUTED, DEFINER,
       EVENT_DEFINITION
FROM INFORMATION_SCHEMA.EVENTS
WHERE EVENT_SCHEMA = 'event_lab'
  AND EVENT_NAME = 'ev_heartbeat';

也可以用 SHOW CREATE EVENT event_lab.ev_heartbeat 复核完整定义，尤其是 STARTS、EVERY、ENABLE 和定义者。不要只看事件名称就下结论。

第三步：把时区问题和调度问题拆开

MySQL 会使用执行 CREATE EVENT 或 ALTER EVENT 时的 session time_zone 解释计划时间，并将事件时区一起保存。之后服务器时区变化，不等于原有事件自动换了排班口径。

SET time_zone = '+08:00';
CREATE EVENT ev_daily_rollup
  ON SCHEDULE EVERY 1 DAY
  STARTS '2026-08-27 02:00:00'
  ON COMPLETION PRESERVE
  ENABLE
  DO INSERT INTO event_heartbeat(fired_at) VALUES (NOW());

查看 TIME_ZONE 和 STARTS 时，要以事件对象报告的时区理解时间。应用日志若统一记 UTC，则应先转换再比较，不能把日志字符串直接和北京时间排班表对照。

第四步：确认事件启动了，但执行体没有失败

事件调度器写入错误或告警到 MySQL Server error log。若 LAST_EXECUTED 有变化而业务表没有预期结果，优先查错误日志和事件定义里的 SQL，而不是反复重建事件。

还要检查定义者权限。创建事件成功，只说明创建语句通过；事件真正执行时，会按 DEFINER 账号检查相关对象权限。定义者被删除、表权限被回收、目标表结构改变，都可能造成“有调度、没结果”。

SHOW GRANTS FOR 'event_owner'@'localhost';
SHOW CREATE EVENT event_lab.ev_heartbeat;

在可控测试环境里，可以把事件体换成一条明确写入心跳表的 SQL，再等待一个周期，用 SELECT * FROM event_heartbeat ORDER BY id DESC LIMIT 5 验证。不要用只返回结果集的 SELECT 作为事件体来判断执行成功，因为结果不会发送到 MySQL Monitor，也不会自动保存。

重复触发：间隔不是并发保护

如果事件单次执行时间超过 EVERY 间隔，MySQL 可能让多个实例同时运行。清理任务、汇总任务和发通知任务都要考虑这个边界。

简单的做法是让任务具备幂等条件，例如按业务日期建立唯一键；更严格的场景可以在事件体中使用数据库锁或一张任务租约表，把“本轮是否已有实例”变成可检查的状态。不要因为偶尔看到两条心跳记录，就先把调度器关闭；先确认执行耗时和业务是否允许重叠。

常见问题

事件已经 ENABLED，为什么还是不执行？

先查 @@global.event_scheduler。事件自身启用不代表服务器调度器启用；之后再看 LAST_EXECUTED、时区和错误日志。

修改服务器时区会改变已有事件吗？

不会简单地按新时区重算。事件创建或修改时的 session 时区会成为事件时区，计划时间按该口径保存和执行。需要换排班口径时，应明确执行 ALTER EVENT 并重新核对元数据。

能用 SELECT 在事件里打印调试信息吗？

不能把普通结果集当日志。用写入诊断表的 INSERT，或检查 MySQL error log；事件里的错误和告警会写入服务器错误日志。

如何避免每分钟事件重叠？

先测单次执行耗时，再用唯一键、租约表或数据库锁做幂等/互斥控制。调度间隔本身不是并发保护。

验收清单：从“存在”到“真的执行”

把一次排查收敛成四个证据：全局 event_scheduler=ON；事件 STATUS=ENABLED 且时区、下一次时间符合预期；LAST_EXECUTED 在周期后更新；目标表或错误日志能证明事件体成功或明确失败。四项缺一项，就不要把“事件已创建”写成“定时任务已上线”。