MySQL 事件调度器如何可靠执行定时清理：启用状态、时区与执行记录

线上清理任务最怕的不是 SQL 写错，而是“看起来已经配置好了”，实际却从未执行。MySQL 的事件调度器由全局开关控制，事件本身又带有时区和状态；如果只盯着 CREATE EVENT 是否成功，过几天仍可能发现历史数据一行没少。

先把“会不会执行”拆成三个状态

下面用一张订单归档表举例。目标是每天凌晨 02:10 清理已经归档超过 90 天的明细，但保留一条执行记录。这个任务至少有三层状态：

排查顺序也按这个层次走。第一层没开，后面所有 SQL 都只是配置；第三层没有记录，任务即使偶尔成功，也很难判断是否漏跑。

配置权限时只给事件需要的能力

创建事件通常需要事件相关权限，执行体还会受到定义者权限与表权限影响。生产环境不要直接用拥有全部库权限的账号创建清理任务，先确认账号能访问目标表，再用最小权限账号完成部署。

SHOW VARIABLES LIKE 'event_scheduler';
SHOW GRANTS FOR CURRENT_USER();
SHOW CREATE TABLE order_archive;
SHOW CREATE TABLE order_cleanup_audit;

这里有一个容易忽略的点：event_scheduler 是服务器级开关。使用 SET GLOBAL event_scheduler = ON 前，先确认变更是否会影响当前实例的运维策略；需要重启后仍保持的环境，应把持久化配置交给实例配置管理，而不是只在命令行临时修改。

把清理事件写成可验证的工作流

先准备审计表。记录量不用追求复杂，能把开始时间、删除行数、结果和错误文本留下即可。

CREATE TABLE order_cleanup_audit (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  started_at DATETIME NOT NULL,
  cutoff_at DATETIME NOT NULL,
  affected_rows INT NOT NULL DEFAULT 0,
  run_status VARCHAR(16) NOT NULL,
  error_message VARCHAR(255) NULL
);

事件体里用事务包住删除与审计写入。下面的 DECLARE CONTINUE HANDLER 把失败转成记录，并回滚删除动作；这样看审计表时，FAILED 不会和“删了一半后写成功”混在一起。

DELIMITER $$
CREATE EVENT ev_order_archive_cleanup
ON SCHEDULE EVERY 1 DAY
STARTS '2026-08-28 02:10:00'
ON COMPLETION PRESERVE
ENABLE
DO
BEGIN
  DECLARE v_cutoff DATETIME;
  DECLARE v_rows INT DEFAULT 0;
  DECLARE v_error VARCHAR(255) DEFAULT NULL;
  DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
  BEGIN
    GET DIAGNOSTICS CONDITION 1 v_error = MESSAGE_TEXT;
    ROLLBACK;
    INSERT INTO order_cleanup_audit
      (started_at, cutoff_at, affected_rows, run_status, error_message)
    VALUES (NOW(), v_cutoff, 0, 'FAILED', v_error);
  END;

  SET v_cutoff = UTC_TIMESTAMP() - INTERVAL 90 DAY;
  START TRANSACTION;
  DELETE FROM order_archive
   WHERE archived_at 

示例把截止时间按 UTC 计算，标题里的“凌晨 02:10”仍是事件的调度时间。业务若按中国自然日清理，应明确把事件时区、截止时间计算和审计展示统一起来，不要让一台服务器的系统时区替读者做决定。

上线前做四道门禁

1. 开关门禁：执行 SHOW VARIABLES LIKE 'event_scheduler'，确认值为 ON。
2. 定义门禁：执行 SHOW EVENTS LIKE 'ev_order_archive_cleanup'，确认 STATUS 为 ENABLED，并核对 TIME_ZONE 与 LAST_EXECUTED。
3. 数据门禁：先用同样的截止条件执行只读统计，确认待清理数量和索引使用符合预期；大表不要在业务高峰首次验证。
4. 记录门禁：检查 order_cleanup_audit 是否出现本轮记录，run_status 必须是 SUCCESS，并对 affected_rows 做合理性判断。

SHOW EVENTS FROM app_db
WHERE Name = 'ev_order_archive_cleanup';

SELECT started_at, cutoff_at, affected_rows, run_status, error_message
FROM order_cleanup_audit
ORDER BY id DESC
LIMIT 5;

如果 LAST_EXECUTED 没更新，先别急着手动执行 DELETE。先确认实例开关、事件状态和事件定义的下一次时间；手动补删会让审计记录失去“自动任务是否工作”的证据。

失败时怎样停、怎样恢复

事件失败后，先看审计表里的错误文本，再检查锁等待、表空间和截止时间是否异常。临时止损可以停用事件：

ALTER EVENT ev_order_archive_cleanup DISABLE;
-- 修复后再启用
ALTER EVENT ev_order_archive_cleanup ENABLE;

恢复前应先解决根因，并用限定时间范围的查询核对待处理数据。若任务连续失败，不要通过缩短周期来“追进度”，否则会增加锁竞争；更稳妥的做法是修复后按小批量补偿，并让每次补偿都写入同一张审计表。

相关问题

event_scheduler 是不是每个事件独立配置的？

不是。它首先是实例级调度开关；事件还要单独处于启用状态，两层都满足才会按计划运行。

为什么 SHOW EVENTS 里有事件，却看不到执行记录？

可能是事件尚未到首次执行时间，也可能是全局调度器关闭、事件被禁用或事件体在写记录前失败。结合 STATUS、LAST_EXECUTED 和审计表一起判断。

定时清理需要写 STARTS 时间吗？

建议写。明确的首次时间便于发布检查和跨时区复核；不要让默认创建时间成为生产任务的隐含起点。

临时停用后，错过的周期会自动补跑吗？

不要按自动补跑来设计。停用期间错过的窗口应由人工核对数据后执行受控补偿，并留下补偿原因和范围。

把一次成功变成可持续的任务

MySQL EVENT 的可靠性不在于语句短，而在于每一层都有可检查的证据：实例开关证明“有人调度”，事件状态证明“任务启用”，时区和首次时间证明“窗口明确”，审计表则证明“这一次实际完成了什么”。把四项检查放进发布清单，后续换实例、改时区或临时停用时，任务才不会变成无人负责的黑盒。