登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

MySQL EVENT 怎样让一次性定时任务执行后自动删除

来源:17golang原创

时间:2026-11-07 20:00:17 345浏览 收藏

如果只是想让 MySQL 在未来某个时间执行一次 SQL,并且执行结束后不再留下事件对象,核心写法是 AT 配合 ON COMPLETION NOT PRESERVE。前者定义一次性的执行时间,后者明确告诉 MySQL:事件完成后不要保留它。

还要注意一个容易忽略的前置条件:Event Scheduler 必须处于开启状态。事件创建成功,不代表调度器一定会执行它。

官方资料:https://dev.mysql.com/doc/refman/8.4/en/create-event.html

一次性 EVENT 的正确写法

下面的例子把一条执行记录写入日志表。事件对象本身会在执行后自动清理,业务日志则由表中的数据负责保留,两者职责不要混在一起。

-- 先准备一张业务日志表,保存任务是否真正执行过
CREATE TABLE IF NOT EXISTS event_run_log (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    job_name VARCHAR(64) NOT NULL,
    executed_at DATETIME NOT NULL
);

-- AT 表示只执行一次;NOT PRESERVE 表示完成后删除事件对象
CREATE EVENT IF NOT EXISTS cleanup_demo_once
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 10 MINUTE
ON COMPLETION NOT PRESERVE
ENABLE
DO
  INSERT INTO event_run_log (job_name, executed_at)
  VALUES ('cleanup_demo_once', CURRENT_TIMESTAMP);

这里没有使用 EVERY,所以它不是周期事件。AT 指向一个时间点,事件到点后执行 DO 后面的语句;NOT PRESERVE 让一次性对象在完成后不继续保留。

ON COMPLETION NOT PRESERVE 为什么会自动删除

一次性事件有两个不同的状态:执行前,它是一个等待调度的数据库对象;执行完成后,它是否还存在,由完成策略决定。ON COMPLETION NOT PRESERVE 选择的是“完成后不保存”。这不是删除业务日志,而是删除事件定义本身。

MySQL 一次性 EVENT 从创建到执行后自动删除的生命周期结构图
图1:MySQL 一次性 EVENT 的生命周期示意图,说明图不是运行截图。

如果需要在执行后仍然查看事件定义,可改为 ON COMPLETION PRESERVE。但这时事件对象会继续留在元数据中,后续运维就需要明确它是否要手工清理。

先确认 Event Scheduler 是否开启

事件调度器关闭时,CREATE EVENT 仍可能成功,但事件不会按计划执行。创建任务前可以先读取系统变量:

-- 查看事件调度器当前状态,OFF 时只创建对象不会自动调度
SHOW VARIABLES LIKE 'event_scheduler';

-- 需要足够的系统变量权限;生产环境先按变更流程评估影响
SET GLOBAL event_scheduler = ON;

如果权限不足,不要把它当成事件语法错误。让有权限的管理员开启调度器,或者把事件调度交给已有的作业平台。应用层重复创建事件,通常会让生命周期更难管理。

怎样判断事件为什么没有执行

排查时按“调度器—时间—状态—完成策略”的顺序看,先排除全局条件,再判断单个事件。

-- 先看事件是否仍存在以及当前是否启用
SHOW EVENTS FROM app_db LIKE 'cleanup_demo_once';

-- 再读取执行时间、状态和完成策略等元数据
SELECT EVENT_NAME,
       STATUS,
       EXECUTE_AT,
       ON_COMPLETION,
       LAST_EXECUTED
FROM INFORMATION_SCHEMA.EVENTS
WHERE EVENT_SCHEMA = 'app_db'
  AND EVENT_NAME = 'cleanup_demo_once';

如果使用了 NOT PRESERVE,执行成功后再查询不到这个事件是预期结果,不应据此判断它没有执行。应改查示例中的 event_run_log,确认业务动作是否留下记录。

MySQL EVENT 从调度器状态到完成策略的排查链路结构图
图2:一次性 EVENT 的排查链路示意图,说明图不是运行截图。

时间写错时会发生什么

AT 需要一个未来的时间点。调度服务器时间、会话时区和业务时区没有统一时,最常见的现象是事件看起来“创建成功但马上消失”,或者执行时间与预期相差几个小时。

尤其是一次性事件使用 NOT PRESERVE 时,如果指定的执行时间已经在过去,MySQL 可能在创建完成后立即按不保留策略清理它。调试时先把时间写成明确的未来值,并记录创建时的服务器时间:

-- 用服务器当前时间计算未来时间,避免手工拼接时区偏差
SELECT CURRENT_TIMESTAMP AS server_now,
       CURRENT_TIMESTAMP + INTERVAL 10 MINUTE AS planned_at;

-- 用明确的未来时间创建一次性事件
CREATE EVENT cleanup_demo_once
ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 10 MINUTE
ON COMPLETION NOT PRESERVE
DO
  INSERT INTO event_run_log (job_name, executed_at)
  VALUES ('cleanup_demo_once', CURRENT_TIMESTAMP);

自动删除与执行审计怎样取舍

如果任务只需要触发一次,推荐让事件对象自动删除,把可追溯性放到业务日志表中。这样可以避免大量过期事件堆积,也不会为了查看历史而保留一堆不可执行的定义。

需求完成策略建议记录位置
只触发一次,不保留定义NOT PRESERVE业务日志表
执行后仍要查看事件定义PRESERVE事件元数据与业务日志
固定周期重复执行使用 EVERY,不要伪装成一次性事件业务日志与运维监控

常见问题

为什么 SHOW EVENTS 查不到刚执行过的事件?

如果事件使用了 ON COMPLETION NOT PRESERVE,执行完成后被清理是正常行为。请查询任务自己写入的日志,而不是只依赖事件定义。

事件创建成功但一直不执行怎么办?

先检查 event_scheduler 是否为 ON,再检查 STATUS、EXECUTE_AT 和服务器时间。不要先重复创建同名事件。

什么时候应该用 PRESERVE?

需要在执行后继续查看定义、等待人工复盘或让运维流程继续管理该对象时,可以选择 PRESERVE。如果只是需要审计,应优先写入业务日志,不必保留事件对象。

总结:一次性 MySQL EVENT 使用 AT 指定时间,使用 ON COMPLETION NOT PRESERVE 固定“执行后自动删除”的意图,同时确认 Event Scheduler 已开启。自动删除的是调度对象,不是任务结果;把结果写入日志表,排查时才有稳定依据。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>