企业官网建设流程全解析

说实话，我刚做后端那会儿，最烦的就是定闹钟半夜起来跑SQL。那阵子业务系统刚上线，订单表里堆了一堆超时未支付的脏数据，每天都要人工清。一开始我偷懒，把清理脚本塞到本地电脑的任务计划里，白天正常跑，晚上开着电脑等触发。结果有一次公司断电，第二天一早用户投诉直接打到客服那边，说是订单状态全都不对。后来我组长给了我一句忠告：数据库能自己干的事，就别让人的电脑去干。我才老老实实去研究MySQL自带的事件调度器，也就是Event Scheduler。如果你也在为“定时清理数据”“定时更新状态”“定时生成报表”这类事发愁，这篇文章应该能帮到你。

1. 认识MySQL定时任务的底层机制

1.1 事件调度器到底是什么

很多人第一次听“事件调度器”这个名字，容易觉得高深。其实就是MySQL内置的一个“闹钟加定时执行器”——你把要执行的SQL写好，设定好触发时间和频率，MySQL自己到点就会在内部执行，不需要你另外写脚本、装框架、开客户端，也不依赖操作系统层面的定时任务。

它最早在5.1版本引入，之后一直是社区版和企业版都自带的免费功能。我身边不少同事平时都在用，但说实话，真正理解它内部状态的人不多，更多人只是会CREATE EVENT就完事了。从实现上讲，事件调度器是跑在MySQL服务内部的一个后台线程。服务器启动时它跟着启动，然后按照事件定义里的时间规则去匹配，时间到了就开一个会话来执行对应的语句。这个会话和普通的客户端连接不一样，你看不到它建立了TCP连接，但在processlist里可能会看到某个连接正在执行你定义的SQL，连接用户显示为event_scheduler，说白了就是调度器自己开的小号。

需要区分的一个点是：它和操作系统里的cron不是一个层面的东西。cron负责在系统层面定时执行命令，比如调mysqldump、调python脚本，它依然要经过客户端连数据库。而事件调度器直接活在数据库进程里，少了一层网络交互，少了一个中间脚本，出问题的环节也就少一个。所以对那种“纯SQL就能搞定”的运维型任务，比如清理旧数据、更新状态、生成统计，用它是最直接的方案。

1.2 调度器的三种开关状态与控制方式

调度器并不是默认开启的。MySQL刚装完，大概率是OFF状态。先看状态：

SHOW VARIABLES LIKE 'event_scheduler';

输出常见的值有三个：ON、OFF、DISABLED。

• ON：调度器运行中，事件会被执行。
• OFF：调度器没开，事件即使存在也不会触发。
• DISABLED：这个比较特殊，是在服务器启动时通过参数强制锁死的，运行中改不回来，只能在启动配置里改回去再重启。

开启方式有两种，对应的场景不一样。

临时开启，不用重启，适合开发环境快速验证：

SET GLOBAL event_scheduler = ON;

注意：这个设置只在当前MySQL实例运行期间有效，重启数据库后会还原成配置里的默认值。

永久开启，在生产环境建议这种方式，修改配置文件，在[mysqld]段下加一行：

[mysqld] event_scheduler=ON

然后重启MySQL生效。如果服务器是用systemd管理的，记得重启后再确认一下event_scheduler的值，有的老版本配置在别的include文件里，改错地方会导致看起来改了却不生效。

我个人的习惯是新增一个独立的配置文件挂进来，而不是直接改主配置文件。这样以后升级、迁移、排查都能一眼看到是哪块配置干了什么，尤其是团队好几个同事实在不想每次翻一大堆注释。

关于DISABLED我再多说一句，它是在启动参数里硬编码的。如果配置写的是event_scheduler=DISABLED，那么运行时执行SET GLOBAL event_scheduler=ON，会直接报错。这一点经常有同事项坑，改完了重启，一看还是OFF，查了半天才发现是DISABLED把路堵死了。

1.3 事件调度器和外部脚本怎么选

我做方案选型时，习惯先列一个对比表，把事件调度器和外部cron脚本的区别摊开看：

实际上有一类需求是必须用到事件调度器的：比如主从复制环境下，需要让主库自动清理归档数据。如果不用事件，而是外部cron连主库执行，那就要求外部机器和主库的网络、认证都稳定。用事件的话，数据库自己执行自己，主从架构下还能通过DISABLE ON SLAVE控制只在主库执行。

当然了，外部脚本也有它的用武之地，比如涉及多库复杂计算后要发邮件通知、要调外部API，那还是写脚本更好。事件调度器更适合“数据库内部自愈合、自维护”的场景。我在实际项目中，大量用它做的是这三类事：清理过期数据、更新超时状态、定时生成统计汇总表。下面第二部分先把它最核心的语法讲透。

2. 定时任务的核心语法与配置要点

2.1 创建事件的基本结构与参数拆解

先看完整的语法骨架：

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：在同一个schema（数据库）里唯一，命名建议统一前缀，比如evt_业务_动作，不要随手起，线上事件多了以后光靠注释去认人也认不过来。
• ON SCHEDULE：核心，定义什么时候执行、执行几次。两种写法：AT指定一次，EVERY指定周期。
• ON COMPLETION PRESERVE / NOT PRESERVE：只在一次性事件里有意义。默认是NOT PRESERVE，也就是一次性事件执行完就自动删了。如果你希望它执行完还留个记录，比如调试用，就写ON COMPLETION PRESERVE。
• ENABLE / DISABLE / DISABLE ON SLAVE：定义事件创建之后的初始状态。DISABLE表示先不激活，方便先写好再手动ALTER EVENT开闸；DISABLE ON SLAVE表示事件定义会同步到从库，但在从库上自动处于禁用状态，避免主从都执行一遍。
• COMMENT：注释，建议一定写，线上环境没注释的事件就是隐患。
• DO：实际执行的内容。可以是一条SQL，也可以是复合语句块，多条语句时用BEGIN...END包起来。

如果让我给一个初学者画重点，我会说第2和第6是必懂项，其余都是控制项，理解之后顺手写，但坑往往藏在控制项里。

2.2 时间调度的两种模式：一次性与周期循环

先看完整示例。一次性事件，比如明天凌晨3点执行一次：

CREATE EVENT evt_one_off_example ON SCHEDULE AT '2025-02-01 03:00:00' ON COMPLETION NOT PRESERVE ENABLE COMMENT '一次性清理演示' DO DELETE FROM demo_log WHERE created_at < NOW() - INTERVAL 7 DAY;

这里我特意加了ON COMPLETION NOT PRESERVE，跑完自动删，事件表里就看不到它了，符合“用完即焚”的直觉。

周期循环，比如每天凌晨2点执行：

CREATE EVENT evt_daily_example ON SCHEDULE EVERY 1 DAY STARTS '2025-02-01 02:00:00' ON COMPLETION PRESERVE ENABLE COMMENT '每日定时清理演示' DO DELETE FROM demo_log WHERE created_at < NOW() - INTERVAL 90 DAY;

关键参数：

• EVERY 1 DAY后面可以接STARTS，表示首次执行时间；如果省略STARTS，就是事件创建的那一刻立刻开始算，等一个周期后执行。
• ENDS则用来设定最晚执行时间，比如一个促销活动定时任务，活动结束日之后就不再需要执行了。
• 时间单位支持比较全：YEAR、QUARTER、MONTH、WEEK、DAY、HOUR、MINUTE、SECOND，甚至组合写法也有，但一般就用常用单位。

一个容易踩的坑是：EVERY 1 DAY STARTS '2025-02-01 02:00:00'，如果当前服务器时间已经过了2点，MySQL会怎么处理？它会立即执行一次，然后下一个周期从2点开始。换句话说，STARTS是首次预定的时间点，不是“从设定时刻起的下一个2点”。这个行为我一开始就没搞清楚，结果有一次事件提前跑了，数据统计口径对不上。排查了半天才发现是STARTS写成了已经过去的时间。所以当你写STARTS时，一定要确认这个时间在未来，否则就等着它立刻执行。

关于NOW()在事件里的用法也值得注意。我推荐在SQL里写成NOW()，让判断逻辑是“相对当前时间拒绝旧数据”。如果写死某个时间点，日期一变就失效或者要反复改。用NOW()配合INTERVAL，即使用户运维忘了调整服务器日期，事件判断逻辑也相对稳定。

2.3 事件的修改、删除与权限控制

事件不是写死不能动的，运维期经常要调整时间、禁用它。

查看当前库里所有事件：

SHOW EVENTS;

更推荐直接查系统表：

SELECT * FROM information_schema.EVENTS;

这张表里能看到事件定义、状态、最后执行时间、开始时间、结束时间，排障非常方便。

修改事件，把上面的每天凌晨2点改成凌晨3点：

ALTER EVENT evt_daily_example ON SCHEDULE EVERY 1 DAY STARTS '2025-02-01 03:00:00';

只禁用不动定义：

ALTER EVENT evt_daily_example DISABLE;

删除：

DROP EVENT evt_daily_example;

权限方面的控制是很多团队忽略的点。创建事件需要EVENT权限，而且事件创建在哪个schema，就至少要这个schema的EVENT权限。如果是全局管理：

GRANT EVENT ON *.* TO 'ops'@'%';

只给某个库的事件权限：

GRANT EVENT ON mydb.* TO 'ops'@'%';

特别注意：事件执行时，它用的是创建者或定义者的权限。换句话说，事件里面执行的SQL，需要的权限是那个账号拥有的权限，不是执行事件的人登录客户端时的权限。我在一个项目里就遇到过：运维A用管理账号创建了事件，后来这个管理账号的权限被收紧了，事件表面还在、状态还是ENABLE，但每次执行都失败，错误日志里报权限不足。排查时一看吓一跳，还以为数据库出了大问题。所以生产环境里，我建议为定时任务单独准备一个专用账号，只授予必要的库表权限，一方面安全，另一方面排查归属也清楚。

3. 三个生产级实操案例

下面进入实操。我用三个真实的业务场景来演示：订单超时取消、日志清理、每日报表汇总。除了表名和字段做了简化，逻辑基本一致。这三个例子分别代表更新类、删除类和插入统计类任务，你后续做其他定时任务时基本也能套用这套思路。

3.1 案例一：订单超时自动取消

电商或预约类业务里，用户下单后迟迟不支付，订单状态一直挂着“待支付”。时间长了不仅占位，还会导致库存被锁、统计失真。我以前在项目里定的规则是：超过30天未支付，订单自动置为“已取消”，同时留一条状态流转日志。

表结构简化如下：

• orders：id, order_no, user_id, status, created_at
• order_logs：id, order_id, old_status, new_status, changed_at

创建事件：

DELIMITER $$ CREATE EVENT evt_order_cancel_overdue ON SCHEDULE EVERY 1 DAY STARTS CURRENT_TIMESTAMP + INTERVAL 1 DAY ON COMPLETION PRESERVE ENABLE COMMENT '每天自动取消超过30天未支付的订单' DO BEGIN DECLARE done INT DEFAULT 0; DECLARE v_order_id BIGINT; DECLARE cur CURSOR FOR SELECT id FROM orders WHERE status = 'pending' AND created_at < CURRENT_TIMESTAMP - INTERVAL 30 DAY FOR UPDATE; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_order_id; IF done THEN LEAVE read_loop; END IF; UPDATE orders SET status = 'cancelled', updated_at = CURRENT_TIMESTAMP WHERE id = v_order_id AND status = 'pending'; INSERT INTO order_logs(order_id, old_status, new_status, changed_at) VALUES (v_order_id, 'pending', 'cancelled', CURRENT_TIMESTAMP); END LOOP; CLOSE cur; END$$ DELIMITER ;

这段代码看起来长，其实核心逻辑就是三步：找出符合条件的订单，逐条改状态，写日志。为什么要用游标而不是一条UPDATE？因为需要同时写日志表，而且我在生产里还可能会根据订单类型去调用别的处理逻辑。如果你只想快速改状态不写日志，一条UPDATE就足够了，完全可以用更简的方式：

CREATE EVENT evt_order_cancel_overdue_simple ON SCHEDULE EVERY 1 DAY STARTS CURRENT_TIMESTAMP + INTERVAL 1 DAY ON COMPLETION PRESERVE ENABLE DO UPDATE orders SET status = 'cancelled', updated_at = CURRENT_TIMESTAMP WHERE status = 'pending' AND created_at < CURRENT_TIMESTAMP - INTERVAL 30 DAY;

注意两点：一，复合语句一定要用BEGIN...END包起来，而创建事件时如果你用MySQL客户端执行，最好把分隔符改掉，不然客户端会把分号当成整个语句结束符，导致语法报错，所以上面加了DELIMITER；二，在事件内部，除非确有必要，不建议大批量一次UPDATE，尤其是有索引扫描范围很大的表，最好带LIMIT分批处理，或者先查主键再按主键更新，避免长事务锁表。

3.2 案例二：日志表数据定期清理

日志表是典型需要定期清理的对象。我们线上的访问日志表按月最多增长千万行，磁盘和查询性能都扛不住。公司没有专门的数据治理平台，所以最朴素的方案就是定时任务定期删除。

最直接的事件写法：

CREATE EVENT evt_clean_access_log ON SCHEDULE EVERY 1 DAY STARTS CURRENT_TIMESTAMP + INTERVAL 1 DAY ON COMPLETION PRESERVE ENABLE COMMENT '清理90天前的访问日志' DO DELETE FROM access_log WHERE log_time < CURRENT_TIMESTAMP - INTERVAL 90 DAY LIMIT 50000;

这里我给DELETE加了LIMIT，目的就是控制每次删除的量，避免一次性删太多造成主库压力。但带来的新问题是：每天只删到LIMIT，可能一天删不完90天外的数据。所以更科学的设计是把删除倍数算好，或者把这个事件调整为每两小时触发一次：

CREATE EVENT evt_clean_access_log_interval ON SCHEDULE EVERY 2 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 1 HOUR ON COMPLETION PRESERVE ENABLE DO DELETE FROM access_log WHERE log_time < CURRENT_TIMESTAMP - INTERVAL 90 DAY LIMIT 50000;

我实际项目里用的是每2小时跑一次，每次最多删5万行。为什么是这些数？主要看表大小和主库负载。你可以用EXPLAIN看删除条件是否走索引，log_time上有索引的话，逐批删除很快，不至于拖垮磁盘IO。

再往深走一步，如果日志表实在太大，几十亿行，DELETE本身就很难受。正确的做法其实是配合分区表来实现DROP PARTITION，那个效率比DELETE高得多。事件调度器在小表和中型表上清理是够用的，大数据量建议先做表分区，再用事件去DROP历史分区。我曾经在一个订单流水表上用过了这个方案：按月建分区，事件的例行任务是每个月执行一次，把两个月前的分区直接DROP掉，效果比DELETE快几个数量级。

3.3 案例三：每日业务统计报表自动生成

很多运营报表其实不需要实时，每日汇总就够。我以前要每天一早把前一天的订单汇总数据跑出来发出去，这个活完全可以交给事件调度器。

先建一张汇总表：

CREATE TABLE daily_order_summary ( summary_date DATE NOT NULL PRIMARY KEY, order_count INT NOT NULL DEFAULT 0, total_amount DECIMAL(12, 2) NOT NULL DEFAULT 0, paid_count INT NOT NULL DEFAULT 0, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

再建事件，每天凌晨1点统计前一天数据：

CREATE EVENT evt_daily_order_summary ON SCHEDULE EVERY 1 DAY STARTS CURRENT_TIMESTAMP + INTERVAL 1 DAY ON COMPLETION PRESERVE ENABLE COMMENT '每日业务报表汇总' DO INSERT INTO daily_order_summary (summary_date, order_count, total_amount, paid_count) SELECT DATE(CURRENT_TIMESTAMP - INTERVAL 1 DAY) AS summary_date, COUNT(*) AS order_count, COALESCE(SUM(total_amount), 0) AS total_amount, SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_count FROM orders WHERE created_at >= CURRENT_TIMESTAMP - INTERVAL 1 DAY AND created_at < CURRENT_TIMESTAMP;

这里有几个要注意的：

• 日期口径：我用“不超过当前时间、超过前一天”这个左闭右开区间，保证不会重复统计。如果你直接用DATE(created_at)=某个日期，表大了性能会很差，因为函数套在列上不进索引。
• 幂等性：这个事件每天跑一次，正常情况下不会重复写同一天的数据，因为summary_date是主键。但万一事件被重复触发，比如线上误操作又手动执行了一遍，由于主键约束，第二次插入会直接报错。更好的写法是INSERT...ON DUPLICATE KEY UPDATE，或者先DELETE再INSERT，让统计操作可重复执行而不出错。
• 汇总表为什么用日期做主键：因为后续报表查询基本都按日期查，主键是最直接的索引，而且天然去重。

如果还想提升可靠性，可以写一个存储过程，在事件里调用：

DELIMITER $$ CREATE PROCEDURE sp_daily_order_summary() BEGIN INSERT INTO daily_order_summary (summary_date, order_count, total_amount, paid_count) SELECT DATE(CURRENT_TIMESTAMP - INTERVAL 1 DAY), COUNT(*), COALESCE(SUM(total_amount), 0), SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) FROM orders WHERE created_at >= CURRENT_TIMESTAMP - INTERVAL 1 DAY AND created_at < CURRENT_TIMESTAMP ON DUPLICATE KEY UPDATE order_count = VALUES(order_count), total_amount = VALUES(total_amount), paid_count = VALUES(paid_count); END$$ DELIMITER ;

然后在事件里DO CALL sp_daily_order_summary(); 这样事件定义非常简洁，业务逻辑都在存储过程里，后续要改统计口径，直接改存储过程就行，不用每次都去ALTER EVENT改那坨SQL。我个人的习惯是：事件做定时外壳，存储过程做业务内核。事件里尽量不要堆复杂SQL，一是维护麻烦，二是事件文本本身存在系统表里，改起来不像文件那么方便。

4. 常见问题与排查技巧实录

4.1 事件到点了却不执行

这是最常被问的问题。事件创建了，状态是ENABLE，时间也到了，但就是没动静。排查顺序我建议按下面这个来：

1. 看开关。执行SHOW VARIABLES LIKE 'event_scheduler'，如果输出OFF，事件当然不会跑。这种情况要么是配置文件没写好，要么是机器重启后被还原了。
2. 看事件本身。查information_schema.EVENTS，看STATUS字段。如果创建的时候写了DISABLE，或者后来有人误操作了ALTER EVENT...DISABLE，事件就不会跑。
3. 看时区和时间。事件判断用的是MySQL服务器本地时间，如果拿手表上的时间比，而服务器时区不对，就会出现“明明到点了没跑”的感觉。可以执行SELECT NOW()看看当前服务器时间，再和业务时间比对。
4. 看错误日志。事件执行报错不会直接弹到你面前，要到MySQL的错误日志里查。常见的是执行SQL报权限不足、表不存在、SQL语法错误。另外每次执行失败，information_schema.EVENTS里的LAST_EXECUTED字段也可能停在上一次成功的时间，能辅助判断。

还有一个特别容易忽略的：事件执行过程中，如果涉及的表被其他事务锁住了，事件SQL会卡住等待锁，表现看起来就是“没执行”。这时候去查processlist，能看到一个event_scheduler开的小会话在等待。解决方案是优化事件里的SQL，尽量短事务，别一次性处理大数据量。

4.2 事件重复执行和幂等设计

所谓重复执行，不是说调度器同一秒跑两遍，而是指事件本身不是幂等的，加上某些边界条件导致不希望它多跑的时候它又跑了一次。比如手动测试时手动执行了一遍，后来线上又到点自动执行了一遍；又比如STARTS写得不对，导致创建后立刻执行了一次。

解决重复执行影响的办法就是让SQL具备幂等性。所谓幂等，就是同一个任务执行一次和执行一百次，最终结果都是一样的。怎么做到？记住几个常见套路：

• 更新类任务带上状态条件，避免重复处理。比如前面订单取消的UPDATE里加了WHERE status='pending'，即使跑了两遍，第二遍已经没有pending订单可更新，不会把已经取消的订单再改一遍。
• 插入类任务用主键、唯一键配合ON DUPLICATE KEY UPDATE，比如报表汇总表。
• 删除类任务本身就是幂等的，删了再删还是删不到。
• 如果实在需要保证每天只执行一次，可以在事件里先通过一个标记表判断。先插入任务运行日志，然后通过ROW_COUNT()判断这次插入是不是新插入，如果是才继续执行后面的统计。这个办法看起来多了一步，但对于严格只跑一次的业务，非常实用。

INSERT INTO task_runtime_log(task_name, run_date) SELECT 'daily_summary', CURRENT_DATE WHERE NOT EXISTS ( SELECT 1 FROM task_runtime_log WHERE task_name = 'daily_summary' AND run_date = CURRENT_DATE );

4.3 主从复制、时区与维护期的问题

先说主从复制。假设你有一主一从，从库用于读，主库用于写。如果你在主库建了一个事件，事件定义会通过binlog同步到从库，从库也会尝试执行。如果业务上其实只需要在从库跑，比如在从库生成报表不影响主库，那就要在创建事件时用DISABLE ON SLAVE，让从库上的副本处于禁用状态。反过来如果只要主库跑，那就要保证从库不会跑，除了DISABLE ON SLAVE之外，还要小心从库的event_scheduler不要打开。

再说时区。MySQL里CURRENT_TIMESTAMP受time_zone参数影响。如果你的服务器和业务方不在一个时区，或者你用了TIMESTAMP字段存时间，数据库迁移、连接会话时区设置不同，都可能导致事件触发时间和你预期不一致。我的建议是：在生产环境把MySQL的time_zone固定下来，不使用系统默认，同时事件里的时间判断尽量用NOW()和CURRENT_TIMESTAMP，不要用字面量写死，避免运维调服务器时间以后，事件判断口径跟业务不一致。

最后说维护期：数据库重启、版本升级、迁移过程中，事件调度器默认是停止状态，事件定义会保留，但需要确认重启后event_scheduler是否置回ON，然后再确认事件STATUS还是ENABLE。我在一次升级MySQL小版本时遇到过事件状态变成DISABLED的诡异情况，后来查证是升级脚本把所有事件重建时默认带了DISABLE参数。所以数据库升级后的例行检查清单里，千万别漏了查事件状态，不然等你意识到，业务早就没跑定时任务了。

5. 几个让定时任务更稳的进阶习惯

5.1 事件执行日志，关键业务必加

我做线上事件调度，一定会配一张事件执行日志表，每次事件跑完都往里插一条记录，记录任务名、执行时间、影响行数、耗时、状态。这样就算事件没按预期执行，也能从日志里定位是没触发、触发了没跑完、跑完报错了，还是压根没到点。日志表可以这样设计：

CREATE TABLE event_exec_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, event_name VARCHAR(128) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NULL, row_count BIGINT DEFAULT 0, status VARCHAR(32) DEFAULT 'running', error_msg VARCHAR(1024) NULL, KEY idx_event_start (event_name, start_time) );

在事件里配合存储过程包一层：开始前插一条status=running，结束时更新成success，异常时更新成failed并记录error_msg。虽然会多写几行代码，但以后排查事件的效率真的天差地别。尤其是多个团队共用一个数据库实例时，没有日志，你连是谁什么时候改了事件定义都查不清楚。

5.2 事件命名规范和版本管理

命名我一般统一成evt_业务_频次_动作，比如evt_order_daily_cancel、evt_accesslog_2h_clean。注释里写清楚执行SQL的用途和变更日期。更进阶一点的做法是，把事件的创建SQL放到版本仓库里管理，和普通表结构变更一样走发布流程。毕竟事件也是数据库对象的一种，线上环境直接CREATE EVENT没问题，但团队协作时最好有个审批和记录。我看到过不少事故，都是因为某个人直接在一个共享实例上创建了一个事件，结果和其他人的定时任务撞了执行时间，把数据库IO打满。规范管理之后，这个问题基本就杜绝了。

5.3 不要过分依赖事件调度器

说了这么多好话，最后也得泼盆冷水。事件调度器适合的是轻量级、数据库内自洽的定时维护。如果你的系统跑的是几百万订单的大规模数据任务，还是要考虑专业的定时调度平台、消息队列或者数据任务编排工具。另外，MySQL事件调度器本身不保证“绝对不丢执行”，比如长时间停机期间到了点，恢复之后并不会补执行。关键业务不要把它当成唯一保障，可以用外部监控来check事件是否在执行窗口内正常跑过，比如在日志表里查最后成功时间，超过阈值就报警。

我个人在实际项目里的体会是，把那些简单重复的运维工作交给事件调度器，最大的收获不是“少敲了几条SQL”，而是“半夜终于不用被电话叫醒了”。定时任务这东西，配置好了就是自动化，配置错了就是定时造故障，所以动手之前，先把业务规则、幂等性、权限边界想清楚，比上手写SQL重要一万倍。