MySQL事件调度器详解：从语法到实战的定时任务方案

1. MySQL事件功能到底是什么，又能帮你省下什么

1.1 一个容易忽略但又极度实用的定时任务方案

先抛个场景。你负责维护一套业务系统，数据库里有一张登录日志表，每天新增几十万行；还有一张临时订单表，业务上要求“超过30天未支付自动取消”。这种需求你第一反应是什么？多半是写个脚本挂到操作系统的crontab里，或者写个后台服务定时扫表。这些方案本身没错，但如果你用的是MySQL，其实数据库内部早就自带了一个能力——MySQL事件调度器（Event Scheduler），也就是大家常说的MySQL事件功能。

它说白了就是：让MySQL自己按照约定好的时间规则，自动执行一段SQL语句或存储过程。你不再需要额外部署脚本进程，不再依赖操作系统定时器，也不用写任何外部代码，只要在数据库里创建一个事件，到了时间它自己就会跑。这个功能在MySQL 5.1版本之后就有了，已经非常成熟，但奇怪的是我接触过不少开发者和DBA，真正用过的人却不多，很多人甚至不知道有这个东西。

MySQL事件功能最适合谁来用？一类是中小团队，没有独立的运维平台和任务调度中间件，但又确实有定时执行SQL的刚性需求；另一类是DBA，需要定期做清理归档、统计汇总这类的数据库内部维护工作。对这两种人来说，事件功能几乎是零成本方案，不需要引入任何额外组件，你在MySQL命令行里敲几条SQL就能把定时任务建好，运行状态随时可以查，出了问题也方便排查。

1.2 哪些场景适合用事件，哪些场景千万别硬上

先说适合的。最常见的是这四类：

• 定期清理过期数据，比如日志表、临时表、会话表，每天凌晨把N天前的数据删掉。
• 定期归档数据，把主表里已经完成的历史订单搬迁到归档表，避免主表越来越大。
• 定时生成报表统计结果，业务方每天早上要看昨日的核心指标，你不用等他们上班查询时现场聚合，凌晨就把结果算好存进统计表。
• 定时执行存储过程，比如批量更新某些字段状态、重算库存、修复脏数据，这些逻辑如果已经写在存储过程里，事件可以直接调用它。

那什么场景别用事件呢？这点我得说清楚，免得有人把它的用途想歪了。首先，实时性要求高的任务不要用事件，事件最小间隔粒度虽然可以设置到秒级，但调度本身有延迟，你拿它做秒杀扣减、消息推送这种高并发实时触发的活，它根本扛不住，那是MQ和定时任务框架的领域。其次，任务逻辑特别复杂的不要硬塞给事件，如果一段逻辑要几十个步骤还依赖外部接口调用，写在存储过程里维护成本极高，这时候你需要的是一套完整的任务编排系统。最后，跨数据库集群的分布式调度别指望事件，事件只在当前实例内执行，它没有分布式协调能力。

一句话总结我的看法：MySQL事件是“数据库内部的轻量定时器”，它能覆盖70%以上“纯SQL层面的周期性操作”需求，但别试图把它变成万能调度中心。

2. 环境准备与事件基本语法拆解

2.1 先确认你的调度器是否开启

动手创建事件之前，一定先确认一件事：事件调度器（event_scheduler）是否处于开启状态。MySQL的事件调度器默认在部分版本中可能是关闭的，这导致不少新手建好了事件却不执行，卡在这一步的人非常多。

查看当前状态很直接，执行这条SQL：

sql复制SHOW VARIABLES LIKE 'event_scheduler';

返回结果如果是 OFF，说明调度器没开，事件建了也不会触发。临时开启可以执行：

sql复制SET GLOBAL event_scheduler = ON;

注意，这个设置是全局级的，执行完立刻生效，不需要重启数据库。但它修改的是运行时的全局变量，MySQL实例重启后会恢复成配置文件里的默认值，所以如果你希望永久生效，必须在my.cnf（或Windows下的my.ini）的 [mysqld] 段里加上一行：

ini复制event_scheduler=ON

加完之后重启MySQL服务，再查一次就能确认永久生效。我在实际操作中的一个习惯是：配置好之后先执行 SHOW PROCESSLIST;，如果能看到一个名为 event_scheduler 的后台线程，那说明调度器已经真正跑起来了。看不到这个线程，配置就还没生效。

提示：如果是云数据库RDS这类托管实例，你可能没有直接修改配置文件的权限，一般在控制台参数组里也能找到 event_scheduler 参数，把值改为 ON 再提交即可。

2.2 创建事件的核心语法结构

事件的核心语法并不复杂，一条CREATE EVENT语句就能搞定，但很多人在第一次写的时候容易漏掉关键部分。完整的标准写法如下：

sql复制CREATE EVENT [IF NOT EXISTS] event_name
ON SCHEDULE schedule
[ON COMPLETION [NOT] PRESERVE]
[ENABLE | DISABLE | DISABLE ON SLAVE]
[COMMENT '注释内容']
DO
    sql_statement;

我把每一段拆开来讲，这样你不仅会用，还能理解为什么这么写。

event_name 是事件名称，在同一个库内必须是唯一的，命名规则跟表名类似。我建议命名时加上业务前缀，比如 evt_clean_login_log、evt_daily_report_summary，一眼就能看出这个事件在干什么。

schedule 是调度规则，是整个语法的核心，具体有两种写法：

sql复制-- 方式一：在指定时间点执行一次
AT TIMESTAMP [+ INTERVAL interval]

-- 方式二：按固定周期重复执行
EVERY interval [STARTS timestamp] [ENDS timestamp]

这里的 interval 由数字和时间单位组成，比如 1 DAY、2 HOUR、30 MINUTE、5 SECOND 都是合法写法。细心的朋友会发现，EVERY 后面如果没有显式写 STARTS，它的默认起始时间就是创建事件的时间。举个典型例子：

sql复制-- 从创建时刻开始，每隔1小时执行一次，永不停歇
EVERY 1 HOUR

-- 指定从明天凌晨2点开始，每隔1小时执行一次
EVERY 1 HOUR STARTS '2025-01-01 02:00:00'

-- 只在某段时间窗口内执行
EVERY 1 DAY STARTS '2025-01-01 02:00:00' ENDS '2025-12-31 02:00:00'

ON COMPLETION [NOT] PRESERVE 这个参数很多人会忽略。它控制的是“一次性事件执行完之后，事件定义是否保留”。默认值是 NOT PRESERVE，意思是如果事件只执行一次，执行完定义就自动删除。如果你希望保留事件定义以便后续重新启用，必须显式加上 ON COMPLETION PRESERVE。针对周期性的重复事件，这个参数其实没啥影响，但如果你要建一次性事件，请想清楚到底要不要保留。

ENABLE / DISABLE 控制事件创建后是否立即生效。默认是 ENABLE 状态，创建即生效。有时候你要先建事件但不希望它马上跑，可以指定 DISABLE，等一切就绪后再手动启用。

DO 后面的 sql_statement 就是事件被触发时要执行的SQL。如果逻辑只有一条SQL，直接写在这里；如果逻辑复杂，建议把逻辑封装成存储过程，然后在事件里调用存储过程，这样管理更清晰。调用写法是 CALL your_procedure();。

2.3 SCHEDULE 的时间单位与细节坑

关于时间单位，MySQL支持 YEAR、QUARTER、MONTH、WEEK、DAY、HOUR、MINUTE、SECOND，以及 YEAR_MONTH、DAY_HOUR、DAY_MINUTE、DAY_SECOND、HOUR_MINUTE、HOUR_SECOND、MINUTE_SECOND 这种复合单位。复合单位用得比较少，日常用单单位即可。

这里有几个我实际踩过坑的地方，值得单独拿出来说。

第一，EVERY 的默认起点是事件创建时间，不是你“以为”的整点。比如你下午3点47分创建了一个 EVERY 1 DAY 的事件，它会在每天下午3点47分执行，而不是凌晨0点。所以业务上如果需要固定在凌晨跑，一定要在 STARTS 里明确写时间。

第二，AT 和 EVERY ... STARTS 使用的时间，是MySQL服务器的本地时区，不是客户端的时区。如果你的应用端和数据库服务器不在同一个时区，要特别注意这个偏差。

第三，事件执行时间不是绝对精确的。MySQL事件调度器本质上是后台线程周期性扫描任务列表，到了触发时间才执行。如果数据库负载很高，或者当时有长事务锁表，事件的实际执行时间可能往后延迟，不会像实时操作系统那样准时。这个特性决定了它不能用在强时间约束的场景里。

3. 三个能直接抄作业的实操案例

3.1 案例一：每天凌晨清理过期日志表

最经典也最直接的需求就是清日志。假设我有一张登录日志表 login_log，表结构大致是 id、user_id、login_time、ip_address，我们约定只保留最近30天的登录记录。

首先把这套清理逻辑封装成存储过程，这样后续如果要在清理的同时做备份或统计，只改存储过程就行，不用动事件定义：

sql复制DELIMITER $$

CREATE PROCEDURE sp_clean_login_log()
BEGIN
    DELETE FROM login_log
    WHERE login_time < DATE_SUB(NOW(), INTERVAL 30 DAY);

    -- 如果删完数据后发现表碎片严重，可以再执行一次表优化
    -- OPTIMIZE TABLE login_log;
END$$

DELIMITER ;

然后创建事件，每天凌晨3点执行这个清理动作：

sql复制CREATE EVENT evt_clean_login_log
ON SCHEDULE EVERY 1 DAY
STARTS '2025-01-01 03:00:00'
ON COMPLETION PRESERVE
COMMENT '每天清理30天前的登录日志'
DO
    CALL sp_clean_login_log();

为什么时间选凌晨3点而不是半夜12点？这是实战经验：凌晨0点前后往往是业务系统定时任务的密集高峰期，比如日终批处理、数据备份都挤在这个时间段。你把数据库清理任务也放在0点，很容易跟其他任务抢资源。选凌晨3点，是对生产环境更温和的错峰做法。

建完事件之后，判断它是否生效，可以执行：

sql复制SELECT name, status
FROM mysql.event
WHERE db = '你的数据库名';

或者直接查 information_schema.EVENTS，这个视图信息更全：

sql复制SELECT EVENT_NAME, STATUS, LAST_EXECUTED, NEXT_EXECUTED
FROM information_schema.EVENTS
WHERE EVENT_SCHEMA = '你的数据库名';

LAST_EXECUTED 和 NEXT_EXECUTED 这两个字段能直接告诉你事件上一次执行时间和下一次计划执行时间，排查问题时特别有用。

3.2 案例二：每天早上生成前一天的订单统计报表

第二个常见场景是预计算报表。假设业务方每天早上9点要看到前一天的订单总量、支付金额、客单价等指标。如果每次都是实时聚合大表，查询压力不小，尤其订单表数据量上去以后，一次聚合可能要扫几百万行。更聪明的做法是凌晨把结果算好存进一张统计表，白天直接查结果。

先建一张统计表，字段按实际需要来：

sql复制CREATE TABLE daily_order_stats (
    stats_date DATE NOT NULL,
    order_count INT NOT NULL DEFAULT 0,
    paid_amount DECIMAL(12,2) NOT NULL DEFAULT 0,
    paid_user_count INT NOT NULL DEFAULT 0,
    PRIMARY KEY (stats_date)
);

再写一个存储过程，把前一天的数据聚合结果插入或更新到统计表：

sql复制DELIMITER $$

CREATE PROCEDURE sp_generate_daily_order_stats()
BEGIN
    INSERT INTO daily_order_stats (
        stats_date,
        order_count,
        paid_amount,
        paid_user_count
    )
    SELECT
        DATE(DATE_SUB(CURDATE(), INTERVAL 1 DAY)),
        COUNT(*),
        COALESCE(SUM(actual_amount), 0),
        COUNT(DISTINCT user_id)
    FROM orders
    WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 1 DAY)
      AND pay_time < CURDATE()
    ON DUPLICATE KEY UPDATE
        order_count = VALUES(order_count),
        paid_amount = VALUES(paid_amount),
        paid_user_count = VALUES(paid_user_count);
END$$

DELIMITER ;

因为 stats_date 是主键，用 INSERT ... ON DUPLICATE KEY UPDATE 可以保证同一天的统计结果如果重复执行也不会产生重复行，而是覆盖更新。这也是一种幂等设计，哪怕某天调度器重复执行了事件，结果依然正确。

然后建事件，每天凌晨1点执行：

sql复制CREATE EVENT evt_daily_order_stats
ON SCHEDULE EVERY 1 DAY
STARTS '2025-01-01 01:00:00'
ON COMPLETION PRESERVE
COMMENT '每日生成前一天的订单统计报表'
DO
    CALL sp_generate_daily_order_stats();

这个案例里有一个值得注意的点：统计任务执行时间在1点，但统计的数据范围是前一天的0点到24点整。我用了 pay_time < CURDATE() 而不是 <=，就是为了避免把当天（执行日）0点之后的数据也算进来。如果你用 <= DATE_SUB(CURDATE(), INTERVAL 1 DAY)，碰到23点59分59.999秒这种边界数据就麻烦了。这类边界条件是统计类SQL最容易出bug的地方。

3.3 案例三：月末自动对账或月度归档

第三个案例更进阶一点，展示事件如何配合“月末”这类非固定日期。假设业务要求每个月最后一天晚上11点，把当月已经完成的订单归档到历史表 orders_archive，然后从主表 orders 中删除这些归档数据。

月度归档不能直接用 EVERY 1 MONTH，因为每个月的最后一天日期不一样，而 EVERY 1 MONTH 会固定在每月同一天执行，比如每月28日，这并不是真正的自然月末。我的处理思路是：事件仍然每天执行，但在存储过程里做判断——只有当天是当月最后一天时才执行归档。

先把归档逻辑写出来。为了简化，假设 orders 表有一个 status 字段，已完成状态为 'FINISHED'，归档条件是“已完成且订单时间早于本月1日”：

sql复制DELIMITER $$

CREATE PROCEDURE sp_monthly_archive()
BEGIN
    -- 如果当天不是本月最后一天，直接退出
    IF DAY(LAST_DAY(CURDATE())) <> DAY(CURDATE()) THEN
        -- 这里什么都不做
    ELSE
        INSERT INTO orders_archive
        SELECT *
        FROM orders
        WHERE status = 'FINISHED'
          AND order_time < DATE_FORMAT(CURDATE(), '%Y-%m-01');

        DELETE FROM orders
        WHERE status = 'FINISHED'
          AND order_time < DATE_FORMAT(CURDATE(), '%Y-%m-01');
    END IF;
END$$

DELIMITER ;

这里有个细节：LAST_DAY(CURDATE()) 返回当前月份最后一天的日期，比如2月返回2025-02-28，闰年则返回2025-02-29。取它的 DAY() 和今天的 DAY() 比较，相等就说明今天是本月最后一天，这个写法在平年和闰年都能正确处理。

事件定义则做成每天晚上9点执行一次：

sql复制CREATE EVENT evt_monthly_archive_check
ON SCHEDULE EVERY 1 DAY
STARTS '2025-01-01 21:00:00'
ON COMPLETION PRESERVE
COMMENT '每月最后一天归档已完成订单'
DO
    CALL sp_monthly_archive();

这种“事件每天检查+过程内条件判断”的模式，其实是解决复杂周期规则的一种通用思路。MySQL事件本身只支持固定的间隔和有限的时间表达式，遇到“每月最后一个工作日”“每年第三个星期四”这类古怪周期，你都可以把判断逻辑放进存储过程，然后让事件高频扫描。这个思路可以说是我用MySQL事件这几年最值钱的一个经验。

4. 事件管理、状态查看与问题排查

4.1 用系统视图掌握事件的执行情况

事件建好之后，定期巡检是很必要的。我常用的查询语句通常是查 information_schema.EVENTS，它比直接查 mysql.event 表更规范，字段信息也更丰富。

sql复制SELECT
    EVENT_NAME,
    STATUS,
    EVENT_TYPE,
    EXECUTE_AT,
    INTERVAL_VALUE,
    INTERVAL_FIELD,
    STARTS,
    ENDS,
    LAST_EXECUTED,
    NEXT_EXECUTED,
    EVENT_COMMENT
FROM information_schema.EVENTS
WHERE EVENT_SCHEMA = 'your_db';

重点关注两个字段：LAST_EXECUTED 表示上次真正执行的时间，NEXT_EXECUTED 表示下一次计划执行的时间。如果你发现事件的 STATUS 还是 ENABLED，但 NEXT_EXECUTED 是空值，说明这个事件是一次性的且已经执行完了，并且可能因为 ON COMPLETION NOT PRESERVE 被系统自动删除。如果 NEXT_EXECUTED 显示的时间离现在越来越远，那很可能是调度器本身出了问题（后面排查部分会说）。

另外一个非常实用的查询是查看 mysql.event 表里的完整事件定义，它会保存创建事件的原始SQL文本：

sql复制SELECT db, name, body, status
FROM mysql.event;

需要修改事件定义时，用 ALTER EVENT 而不是删除重建。ALTER EVENT 可以修改调度规则、执行逻辑、状态等，且不会改变事件的创建时间。有一个我特别推荐的习惯：修改事件前把当前的定义先查出来保存到文本里，万一改错了可以快速恢复。这跟改存储过程之前先备份是一个道理。

启用、禁用、删除事件分别对应三条命令：

sql复制ALTER EVENT evt_clean_login_log ENABLE;
ALTER EVENT evt_clean_login_log DISABLE;
DROP EVENT IF EXISTS evt_clean_login_log;

4.2 事件不执行的常见排查思路

事件建好了但不执行，是在社区里被问得最多的问题。我这里把排查思路整理成一套固定流程，按顺序排查基本都能解决。

第一步：查调度器开关。 这是最容易被忽略的。执行 SHOW VARIABLES LIKE 'event_scheduler';，如果返回值是 OFF，事件自然不会执行。也别只看这个变量，再看一眼进程列表里有没有 event_scheduler 线程：

sql复制SHOW PROCESSLIST;

理论上你会看到一个用户是 event_scheduler、Command是 Daemon 的线程。如果变量显示 ON 但找不到这个线程，说明情况异常，一般需要重启MySQL服务恢复。

第二步：确认事件的STATUS是ENABLED。 执行我上面那套查询，看 STATUS 字段。如果是 DISABLED，说明事件被手动禁用过。这里注意一个特殊情况：如果MySQL重启过，而事件是在旧版本中用 DISABLE ON SLAVE 创建的从库事件，状态可能一直是禁用。

第三步：检查时间范围。 看 STARTS 和 ENDS 字段。如果事件的调度时间窗口已经过期，NEXT_EXECUTED 会是空，事件也不会再触发。这类问题多半是建事件时 ENDS 写得太短，或者一次性事件执行完就被系统删了。

第四步：看执行日志和报错信息。 事件执行失败后，错误会写到MySQL错误日志中。Linux下常见的查找方式是：

bash复制tail -100 /var/log/mysql/error.log

Windows下则一般在数据目录下的 hostname.err 文件里。我遇到最多的事件执行报错包括：存储过程里的SQL语法错误、权限不足（事件执行者没有对应的表操作权限）、表被锁等待超时。事件执行失败了，LAST_EXECUTED 这个字段通常会更新为最近一次尝试执行的时间，但结果显示的操作没有生效，这时候就要靠错误日志定位真正的根因。

第五步：确认时区和系统时间。 如果事件执行时间和你预期的时间差了几个小时，多半是MySQL服务器时区或者系统时区的问题。你可以执行：

sql复制SELECT NOW(), @@global.time_zone, @@session.time_zone;

来确认当前MySQL使用的时区。这个排查点在跨时区的数据库实例上尤其常见。

4.3 主从复制环境下的事件注意事项

在主从架构下使用MySQL事件，有一个非常容易踩的坑：事件在从库上重复执行。

设想一下这个场景：你在一台MySQL主库上创建了一个每天清理数据的事件，这个事件的定义会被记录到binlog中，然后同步到从库。由于从库接收到的是相同的CREATE EVENT语句，它会在从库上创建一个同名事件。这样一来，主库每天凌晨3点清理一次，从库也会每天凌晨3点自己清理一次。如果你的从库数据就是用来处理查询的，主库清完从库也清了，看起来问题不大；但如果你的清理逻辑里有“删除后归档到另一张表”这种操作，就可能出现主库删了、从库也删了，归档表里却写了两份同样数据的问题，逻辑就乱了。

更严重的情况是：从库自己执行事件后产生的数据变更不会写回binlog（从库通常不记录二进制日志），所以从库执行的结果不会再次传播到其他下游库。这时候如果从库还要继续级联同步给其他实例，数据一致性就可能出问题。

我的建议是：在从库上显式禁用事件。创建事件时加一个 DISABLE ON SLAVE 选项，这样事件定义会同步到从库，但从库上的事件默认是禁用状态，不会执行：

sql复制CREATE EVENT evt_clean_login_log
ON SCHEDULE EVERY 1 DAY
STARTS '2025-01-01 03:00:00'
ON COMPLETION PRESERVE
DISABLE ON SLAVE
DO
    CALL sp_clean_login_log();

如果你管理的是一主多从架构，这种处理尤为关键。当然，也有一种情况是故意让从库执行某些只读性质的任务（比如从库只在凌晨汇总统计自己的数据），那你可以单独在从库手动创建事件，不对它做binlog同步。

复制环境下还有一个隐藏问题与参数 log_bin_trust_function_creators 有关。在MySQL 8.0及部分5.7版本中，如果要通过事件调用存储过程或者函数，而二进制日志开启且没有 SUPER 权限，可能触发“you must declare a function before it can be used in a trigger”这类错误。实际操作中，我会在创建事件前先把存储过程建好，并确保创建事件时使用的账号有足够的权限。

5. 事件调度器的进阶使用技巧与性能考量

5.1 事件 + crontab：为何不直接把定时任务全扔给数据库

有些人可能会问：既然有事件调度器这么方便，那是不是所有定时任务都应该写在数据库里？我的回答是：不要走极端。

MySQL事件的最大优势是“离数据近”——不需要额外的网络调用，不需要数据出库，安全边界清晰，部署简单。但它也有明显的短板：无法做跨系统的任务编排。比如你的定时任务要“先从接口拉数据，然后清洗写入数据库，再发通知”，这种逻辑如果全塞进存储过程和事件里，存储过程会变得无比臃肿，调试也会非常痛苦。

我个人的实践经验是：如果任务的执行逻辑能用一条或几条SQL描述清楚，优先用事件；如果任务涉及外部依赖、条件判断很复杂，或者需要按依赖顺序执行多个子任务，那应该用crontab + 脚本或者一套任务调度平台去管理，事件本身只负责数据库终端的最后一个SQL动作。

另外一个很多人没注意到的点：事件调度器的线程是单线程的，同一时刻只会触发一个事件。如果上一个事件执行时间太长，下一个事件会等着，不会并行跑。如果你的业务里真有大量事件需要同时执行，要么把执行时间段错开，要么把耗时逻辑事务拆小，避免事件排队导致严重延迟。

5.2 让人省心的日常维护建议

最后分享几条我在实际运维中总结出来的经验，都是常规文档里不会告诉你的。

第一，给事件加上统一的前缀和注释。 数据库里的事件如果多了，命名不统一会非常难受。我习惯用 evt_ 开头，后面跟业务名和动作，比如 evt_clean_login_log。COMMENT 里一定要写清楚这个事件是干什么的、为什么这么设计。半年后再回头看，你会感谢当年写注释的自己。

第二，重要事件要加结果告警。 不过MySQL事件本身没有内置告警能力，我的做法是在存储过程里增加一个“结果标记表”。每次事件执行完，往表里写入执行时间、影响行数、执行状态，然后由外部监控脚本定时检查这个表。这样即使事件没跑或者跑失败了，你也能第一时间从监控里发现问题。

第三，定期检查事件的状态和执行时间。 我一般是每周看一次 information_schema.EVENTS，重点看有没有事件被意外禁用、NEXT_EXECUTED 是否正常、LAST_EXECUTED 是否和预期周期匹配。这听起来挺无聊的，但确实能帮你提前发现很多问题。有一次我排查一个数据库“每天早上的统计结果都不对”的故障，最后发现就是事件在某个版本升级后被修改了状态，这类问题很隐蔽。

第四，在开发环境一定要测试事件在时间跳变时的行为。 比如操作系统时间被回拨（NTP校正）或者mysql服务重启，MySQL的 NEXT_EXECUTED 计算可能出现一些特殊表现。我在测试环境专门构造过这种场景：把一个 EVERY 1 MINUTE 的事件配在服务重启时间附近，观察它是否会漏执行或重复执行。实测发现重启之后它可能会略过一段时间窗口，然后继续正常执行。这类细节如果你提前没测试过，上线后遇到会非常困惑。

5.3 一次真实案例：事件压垮数据库的教训

最后讲一个我自己踩过的大坑，希望能帮你避免重复交学费。

有一年我负责的一套系统里，有张流水表膨胀得特别快，当时我很自然地想用事件来定期归档。但在设计“归档+清理”这个事件时，我只写了 DELETE FROM 流水表 WHERE create_time < DATE_SUB(NOW(), INTERVAL 6 MONTH)，没有限制每次删除的行数。结果某天这表累积的海量数据一次触发，单条DELETE语句扫了上亿行，直接把生产库的IO打满，业务延迟飙升，最后只能紧急 kill 掉执行中的事件线程才恢复。

这里面有两层反思。第一，大批量删除数据必须分批处理。单条 DELETE 一次删除海量行，不仅持锁时间长，还容易导致主从延迟爆炸。正确写法应该是一次只删几千行，循环删除直到没有满足条件的行，类似这样：

sql复制DELIMITER $$

CREATE PROCEDURE sp_archive_flow_records()
BEGIN
    DECLARE v_count INT DEFAULT 1;

    WHILE v_count > 0 DO

        DELETE FROM flow_record
        WHERE create_time < DATE_SUB(NOW(), INTERVAL 6 MONTH)
        LIMIT 5000;

        SET v_count = ROW_COUNT();

        -- 每次删完停一下，避免持续压过高
        DO SLEEP(1);
    END WHILE;
END$$

DELIMITER ;

第二，删除任务要设置合理的并发控制。如果同一时间还有大量的业务写操作，事件执行期间需要避免跟业务高峰重叠，这也是我把清理类事件尽量安排在凌晨的原因。

从那以后，我再写任何事件里的SQL，都会先在测试库模拟大表数据，估算执行时间，确认不会影响核心业务，再部署到生产。这个教训值得所有打算在生产库上用事件的人记住：事件虽然语法简单，但它背后的SQL执行逻辑仍然要接受生产环境的严格审视。