MySQL 事件调度器怎样安全执行周期任务

我第一次把定时清理放进 MySQL 事件时，真正容易漏掉的不是 EVERY 语法，而是三个边界：服务器有没有启动调度器，事件定义者有没有目标表权限，以及任务失败后能不能留下线索。把这三件事分开，周期任务才不会变成“事件还在，但数据没有变化”的黑盒。

下面用每 15 分钟清理过期会话的例子，给出一套适合生产改造的写法：小批量处理、显式记录、可查询状态、可暂停，并在复制环境里避免副本重复执行。

适合谁：需要在 MySQL 内部执行清理、汇总或归档 SQL，又希望任务有明确权限和排障入口的开发者、DBA。

先把调度开关、定义者和目标表分开

MySQL 事件由专门的 Event Scheduler 线程负责调度。事件定义成功，不代表它一定会运行；服务器变量 event_scheduler 需要处于 ON。另外，创建事件需要 EVENT 权限，但事件真正执行 SQL 时使用的是定义者的权限，所以只授予 EVENT 而不给目标表的 DELETE、INSERT 或 SELECT，任务仍可能每次执行失败。

-- 先确认服务器是否真的开启事件调度
SHOW VARIABLES LIKE 'event_scheduler';

-- 用专门账号承载事件，实际密码应通过安全方式设置
CREATE USER 'event_worker'@'localhost' IDENTIFIED BY '请替换为安全凭据';

-- EVENT 只控制事件对象，不等于拥有业务表的写权限
GRANT EVENT ON app.* TO 'event_worker'@'localhost';
GRANT SELECT, INSERT, DELETE ON app.sessions TO 'event_worker'@'localhost';
GRANT INSERT ON app.job_runs TO 'event_worker'@'localhost';

-- 只在明确授权的维护窗口启用全局调度器
SET GLOBAL event_scheduler = ON;

这段 SQL 的关键是把“能不能创建事件”和“事件能不能操作数据”拆开。生产账号不应直接复用拥有大量管理权限的账号；如果任务只清理和记录，就只给它需要的表级权限。图中的 DEFINER 不是装饰字段，它决定了事件执行时的身份。

把周期任务写成有上限、可追踪的事件

周期任务最怕一次扫完整张表。与其让每次执行都承担不可预测的锁和日志压力，不如给清理动作加批量上限，并把一次执行写入审计表。下面的示例假设 app.sessions 有 expires_at 字段，app.job_runs 用于记录任务状态。

-- 审计表只保存本任务需要的最小信息
CREATE TABLE app.job_runs (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  event_name VARCHAR(64) NOT NULL,
  ran_at DATETIME NOT NULL,
  affected_rows INT UNSIGNED NOT NULL,
  PRIMARY KEY (id),
  KEY idx_job_runs_name_time (event_name, ran_at)
);

DELIMITER |
CREATE EVENT app.ev_purge_expired_sessions
  ON SCHEDULE EVERY 15 MINUTE
    STARTS CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
  ON COMPLETION PRESERVE
  ENABLE
  COMMENT '分批清理过期会话并记录结果'
  DO
  BEGIN
    -- 用固定上限控制单次锁定和日志规模
    DELETE FROM app.sessions
    WHERE expires_at 

EVERY 表示重复周期，STARTS 把首次运行错开一点，便于避开部署瞬间的其他写入。LIMIT 5000 不是性能保证，而是把一次任务的影响面设成可估计的上限；如果积压很多数据，后续周期继续处理即可。

ON COMPLETION PRESERVE 适合希望保留事件定义、方便后续查看和调整的场景。事件中的 SELECT 如果只是返回结果集，并不会自动显示在客户端，所以需要把结果写入审计表或日志相关表。目标表名也尽量写成带 schema 的完整名称，避免默认库变化带来误删。

从 EVENTS 和日志判断是否真的执行

排查时不要只运行 SHOW EVENTS 看一眼。先看事件的定义者、状态、下次时间和最近执行时间，再用 SHOW CREATE EVENT 对照保存的 SQL；如果权限不足或 SQL 本身执行失败，服务器错误日志通常比“事件存在”更能说明问题。

-- 查看当前库中事件的状态和最近执行时间
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, DEFINER,
       EVENT_TYPE, INTERVAL_VALUE, INTERVAL_FIELD,
       STARTS, ENDS, LAST_EXECUTED
FROM INFORMATION_SCHEMA.EVENTS
WHERE EVENT_SCHEMA = 'app'
  AND EVENT_NAME = 'ev_purge_expired_sessions';

-- 核对事件实际保存的定义，不要只相信部署脚本
SHOW CREATE EVENT app.ev_purge_expired_sessions;

-- 观察事件对象管理操作的计数，不等于事件主体 SQL 的影响行数
SHOW STATUS LIKE '%event%';

判断可以按三个结果分层：STATUS 不是 ENABLED，先看事件开关；状态已启用但 LAST_EXECUTED 为空，重点查调度器、STARTS 和定义者；最近执行时间有变化但 job_runs 没有记录，则要检查事件主体是否在第一条语句就失败，以及定义者对审计表是否有 INSERT 权限。不要把 SHOW STATUS LIKE '%event%' 的计数当成任务实际执行次数，它主要统计事件对象相关语句。

为暂停、复制和恢复留下开关

周期任务也应该有“刹车”。发现清理条件写错时，先禁用事件，再修改定义；不需要删除对象才能止损。复制环境还要明确任务应该在哪个节点执行，避免源库和副本同时处理同一份业务数据。

-- 紧急暂停：保留定义，避免恢复时重新手工拼 SQL
ALTER EVENT app.ev_purge_expired_sessions DISABLE;

-- 修改周期或批量上限后，再显式启用
ALTER EVENT app.ev_purge_expired_sessions
  ON SCHEDULE EVERY 30 MINUTE
  ENABLE;

-- 在复制到副本的事件上禁止副本执行，避免重复消费
ALTER EVENT app.ev_purge_expired_sessions DISABLE ON REPLICA;

最后一条只适用于你已经确定“任务只应在源端运行”的复制设计；如果副本承担独立报表或清理职责，就要把节点职责、权限和目标表拆开，而不是机械套用。还要记住，撤销账号的 EVENT 权限不会自动删除或禁用已创建的事件，变更账号生命周期时必须单独盘点事件。

常见疑问

为什么事件显示 ENABLED，却没有数据变化？ 先确认 event_scheduler 为 ON，再核对 DEFINER 是否拥有目标表权限，并查看错误日志；启用状态只说明对象可调度，不证明主体 SQL 成功。

周期事件要不要写 STARTS？ 不写时会从创建后开始重复；写上它可以把首次执行错开部署高峰，并让调度时间更容易被审查。

什么时候用 DISABLE，什么时候 DROP？ 需要临时止损或保留恢复路径时用 DISABLE；确认任务永久废弃并已完成替代方案后，再考虑 DROP EVENT。

安全执行周期任务的重点不是把 SQL 塞进 CREATE EVENT，而是让调度开关、定义者权限、单次影响面、审计记录和暂停入口各自清楚。按这个顺序设计，出现“事件在但没执行”时，排查才有落点。