MySQL 8.4 事件调度器怎么管理周期任务：定义、执行记录与停用检查

线上有一批已经完成支付、但超过 30 天的订单需要归档。把任务放在应用服务器的定时器里，常见结果是发布时漏了一次，或者数据库迁移后没人记得恢复定时任务。MySQL 8.4 的事件调度器可以把周期任务作为数据库对象管理，但它不会替你记录业务结果，所以“建出来”和“确认跑过”必须分开处理。

先确认调度器真的处于可执行状态

事件定义保存在数据库里，但调度器关闭时不会按计划执行。先看全局状态：

SHOW VARIABLES LIKE 'event_scheduler';
SHOW PROCESSLIST;

如果值是 OFF，创建事件仍可能成功，但不能把“对象存在”当成“任务会运行”。在测试环境可以用：

SET GLOBAL event_scheduler = ON;

生产环境是否持久化这个设置，要结合启动配置、权限和主从拓扑评估。不要只在当前会话里改一个变量，然后把验证结果写成上线结论。

用一张执行记录表接住周期任务的结果

事件中的查询结果不会自动回到执行它的客户端，也不会凭空形成业务日志。先准备一张足够小的记录表：

CREATE TABLE event_run_log (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  event_name VARCHAR(64) NOT NULL,
  started_at DATETIME(6) NOT NULL,
  affected_rows INT NOT NULL,
  outcome VARCHAR(16) NOT NULL,
  KEY idx_event_started (event_name, started_at)
);

CREATE TABLE shop_orders (
  id BIGINT PRIMARY KEY,
  paid_at DATETIME NOT NULL,
  archived_at DATETIME NULL,
  status VARCHAR(16) NOT NULL,
  KEY idx_archive_scan (status, paid_at, archived_at)
);

记录表的价值不在于写得复杂，而在于它能回答三个问题：哪一个事件写入的、什么时候开始、这次影响了多少行。若任务还需要保存错误详情，可以增加短文本字段，但不要把大段业务数据塞进每一轮日志。

定义事件时把时间边界和幂等条件写清楚

下面的任务每 1 小时寻找已支付超过 30 天、尚未归档的订单。先用同一组条件手工验证查询，再交给调度器：

CREATE EVENT ev_archive_paid_orders
ON SCHEDULE EVERY 1 HOUR
STARTS CURRENT_TIMESTAMP + INTERVAL 5 MINUTE
ON COMPLETION PRESERVE
ENABLE
COMMENT 'Archive paid orders older than 30 days'
DO
BEGIN
  DECLARE changed_count INT DEFAULT 0;

  UPDATE shop_orders
  SET archived_at = CURRENT_TIMESTAMP,
      status = 'archived'
  WHERE status = 'paid'
    AND paid_at 

这里的 status = 'paid' 和 archived_at IS NULL 是幂等护栏：同一批订单再次扫描时不会重复改变已经归档的行。真正上线前还要检查事件定义时保存的 SQL mode、执行者权限和时区约定。

从事件元数据和业务日志两侧核对是否执行

先查看数据库记录的事件状态：

SHOW EVENTS FROM shop;
SHOW CREATE EVENT shop.ev_archive_paid_orders;

SHOW EVENTS适合确认 STATUS、执行时间和下一次计划；SHOW CREATE EVENT适合确认实际保存下来的周期、注释和主体。它们证明的是“调度对象是什么”，不是“业务更新一定成功”。

业务侧要查执行日志：

SELECT event_name, started_at, affected_rows, outcome
FROM event_run_log
WHERE event_name = 'ev_archive_paid_orders'
ORDER BY started_at DESC
LIMIT 10;

如果事件显示为 ENABLED，但日志没有新记录，先查调度器状态、事件所属 schema、时区和定义者权限；不要马上改周期。若日志有记录但影响行数为零，再看筛选条件和数据是否已经归档。

修改、停用和删除要留回滚路径

临时停跑优先用 ALTER EVENT：

ALTER EVENT shop.ev_archive_paid_orders DISABLE;
SHOW EVENTS FROM shop LIKE 'ev_archive_paid_orders';

需要调整周期时，先停用再改计划，完成后重新启用，并把变更前后的 SHOW CREATE EVENT 结果留在变更记录里。确认事件不再需要时才执行：

DROP EVENT IF EXISTS shop.ev_archive_paid_orders;

一次性事件是否在完成后保留，取决于 ON COMPLETION。周期事件则更要关注迁移和复制场景：旧实例上的事件可能还存在，新实例也可能被恢复出来，切换前必须明确哪一台负责执行。

上线前用一轮最小验收收口

• 调度器：event_scheduler 已开启，且启动配置不会在重启后悄悄关闭。
• 定义：周期、起始时间、状态、schema 和执行者与变更单一致。
• 数据：更新条件可重复执行，第二次运行不会重复归档。
• 记录：每轮至少有事件名、开始时间、影响行数和结果状态。
• 停用：可以用 ALTER EVENT ... DISABLE 暂停，并能通过 SHOW EVENTS 验证。

常见问题

CREATE EVENT 成功了，为什么任务没有执行？

先查 event_scheduler 是否开启，再核对事件状态、schema、计划时间和定义者权限。对象创建成功不等于调度器正在工作。

事件里的 SELECT 结果去哪了？

单纯返回结果集的 SELECT 不会显示在 MySQL 客户端，也不会自动存档。需要把结果写入日志表，或使用 SELECT ... INTO 等有明确落点的语句。

为什么要在事件里记录 ROW_COUNT？

它能把“任务执行过”和“任务实际改了数据”区分开。影响行数长期为零时，可能是数据已经处理完，也可能是筛选条件失效。

事件停用后还要保留吗？

短期故障排查通常保留并禁用，便于恢复；永久下线时再删除，同时保留定义和最后一次执行记录，避免以后无法解释历史数据变化。

事件调度器适合放置边界清晰、可重复执行、结果可记录的数据库内任务。把调度状态、事件定义和业务执行日志分开核对，周期任务才不会变成一段没人敢碰的隐藏 SQL。