凌晨两点手机弹出一条磁盘告警一张三个月没清理的日志表把实例撑到了快满。相信不少搞数据库运维或后端开发的人都经历过这种场景——数据清理、报表汇总、归档删除这些脏活本身不难难的是怎么让它们“按时自动执行”。MySQL事件Event Scheduler就是MySQL内置的定时任务调度器它相当于给数据库装了一个守护进程能按指定时间自动执行SQL语句或存储过程不需要额外装cron、不需要写外部脚本甚至不用依赖应用服务器的操作系统。简单点说事件功能适合所有想让“数据库内部工作自动转起来”的人想定时清理历史数据的DBA、想做每日统计报表的后端、想给业务表做定期归档的架构师都能用它替代一批结构松散的定时脚本。这篇文章我会从实际使用的角度出发讲清楚事件是怎么运转的、怎么建、怎么排障以及我在生产环境里踩过的那些真坑。1. 定时任务落在数据库内部MySQL事件能替你省掉多少事1.1 用cron跑数据库定时任务的三个麻烦很多人一开始处理定时清数、定时汇总第一反应都是“在服务器上写个cron到点跑一段SQL”。这条路看似简单实际用久了麻烦不少。第一是任务脚本散落。脚本文件可能落在某台应用服务器上也可能是某人的个人机器上。数据库一旦迁移、机器一旦重装脚本就跟着失联没人记得那个清理任务在哪台机器上挂着。第二是网络链路不稳定。应用服务器和数据库不在同一个内网时定时脚本连数据库偶尔会碰到防火墙变更、连接超时、掉线重连等问题任务看起来跑了实际可能没执行成功而且很难第一时间发现。第三是多实例扩展时的处理成本高。你从单库拆成主从或者上了多个业务分片每个节点都要单独部署一套cron脚本谁跑过了、谁没跑排查一轮就很费劲。如果把定时任务直接放进MySQL事件里这些问题会被简化不少任务定义就在数据库里跟着数据库走迁移库的时候事件可以一并导出多实例上也只需要在对应实例创建对应事件。而且事件调用的SQL直接走本机连接少了一层网络抖动风险。1.2 MySQL事件调度器是个什么角色MySQL事件本质上是一种“存储在数据库内部的定时程序”。它由事件调度器Event Scheduler统一管理调度器会在后台不断判断当前时间到了哪个事件的下一次执行时间到了就去执行该事件对应的SQL或存储过程。从MySQL 5.1版本开始这个功能就已经内置了到现在依旧是数据库原生定时任务最顺手的一种方案。它的用法和我后面要讲到的存储过程配合得很好事件负责“定时”存储过程负责“做事”两者组合就能实现很多自动化运维动作。用我平时最直白的理解来说事件就是“数据库里的cron”。但它和cron有一个关键区别事件的执行主体是MySQL实例本身它不依赖外部进程也不会因为服务器重启后忘了拉起任务而失效。只要MySQL服务正常起来调度器就会按照事件定义的时间计划继续工作。1.3 哪些场景用事件最合适根据我日常的实践事件特别适合这几类任务定期清理删除过期日志、临时表、历史流水避免数据无限膨胀。定时汇总每天凌晨计算前一天的订单汇总、用户留存、PV/UV这类统计结果。数据归档把冷数据搬运到归档表或者在业务低峰期完成大表分区切换。健康检查定期扫描长期未成交的订单、超时的支付单自动做状态流转。分布式锁释放比如定时释放一些死锁业务留下的资源标记。它不适合的场景也很明确不适合高频率的秒级任务毕竟事件的触发和SQL执行本身有开销秒级甚至毫秒级调度不建议硬塞给数据库也不适合需要调用外部HTTP接口、读写文件系统之类的复杂业务逻辑那种活还是交给消息队列或专门的任务调度框架更合理。2. 事件调度的底层逻辑状态、线程与时间判定2.1 event_scheduler的三种状态先记住一个参数event_scheduler。它有三种取值实际含义差得很远。状态含义能否动态设置ON调度器运行事件按计划执行可以SET GLOBAL event_scheduler ON;OFF调度器未运行事件不执行但事件定义保留可以SET GLOBAL event_scheduler OFF;DISABLED调度器已被禁用事件不执行且无法动态开启不可以必须改配置文件后重启实例这里有一个我见过很多人忽略的坑OFF和DISABLED表面看都是“不执行”但OFF状态还能用SET GLOBAL event_scheduler ON随时打开DISABLED状态是启动时通过[mysqld]配置项或启动参数锁死的它不会因为你在会话里执行SET GLOBAL就改变必须修改配置并重启MySQL才生效。所以生产环境初始化数据库时如果打算用事件功能建议直接把配置写进my.cnf[mysqld] event_schedulerON这样实例每次重启后事件都能自动恢复执行而不是手动去开一遍。不同MySQL版本的默认值有差异有些5.x版本默认是OFF新版本普遍默认ON但不同安装包和发行版的默认配置不一定一致所以别靠默认值自己显式设置最稳。2.2 调度器线程在忙碌什么当你把event_scheduler设置为ON后MySQL内部会启动一个常驻后台线程专门负责事件调度。你在实例上用SHOW PROCESSLIST或者SHOW FULL PROCESSLIST会看到一个名为event_scheduler的线程Command列显示为Daemon这就是它。这个线程的工作方式很像是“闹钟管理员”定期扫描当前库中所有事件的下一次执行时间找出已经到期的事件触发对应的SQL执行。理论上它并不保证严格精确到秒而是周期性扫描所以事件一般不是毫秒级准时的调度器。如果你想依赖事件做“整点零分零秒必须更新缓存”这种强时序逻辑那不是一个好主意。另外要注意调度器线程只负责“发起”执行真正的SQL执行还是交给新建的连接线程。事件执行过程中如果发生卡顿、锁等待影响的是该事件自己的执行进度一般的慢查询不会长时间阻塞调度器线程本身。2.3 事件的时间计划如何计算事件的时间计划由AT和EVERY这类子句决定MySQL会为每个事件记录一个“下一次执行时间”。每次执行完成后如果是周期性事件系统会根据事件的间隔设置自动计算新的下一次执行时间如果是一次性事件执行完事件就结束了。这里涉及到时区问题比如我的服务器系统时区可能是UTC而数据库写入的统计时间是东八区如果事件的STARTS时间写的是2024-01-01 02:00:00那实际触发行为会受MySQL系统时区的影响可能和你想的并不一致。所以强烈建议在创建事件之前先统一确认好实例的系统时区和会话时区否则很容易出现“每天凌晨跑出来的数据是前一天或后一天的”这种诡异问题。3. CREATE EVENT一条语句过关语法拆解和易错点3.1 最基础的建事件语句先看一个最典型、也最常见的例子每天凌晨3点删除180天前的操作日志。CREATE EVENT ev_clean_old_log ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 03:00:00 DO DELETE FROM operation_log WHERE created_at NOW() - INTERVAL 180 DAY;这个语句结构拆开看ev_clean_old_log事件名称一台实例里建议全局唯一方便排查。ON SCHEDULE EVERY 1 DAY表示周期性执行间隔为1天。STARTS 2024-01-01 03:00:00表示从哪天开始生效。DO DELETE FROM ...事件触发时执行的SQL语句。如果你希望事件创建后立刻开始计时也可以把STARTS省略那么默认创建后就会开始计算执行周期。另外STARTS可以写成CURRENT_TIMESTAMP INTERVAL 1 HOUR这种相对时间形式兼容性更好一些。3.2 ON SCHEDULE的三种计划写法与时间单位事件的调度计划有三种基础写法覆盖绝大多数需求-- 一次性事件10分钟后执行一次 ON SCHEDULE AT CURRENT_TIMESTAMP INTERVAL 10 MINUTE -- 周期性事件每2小时执行一次 ON SCHEDULE EVERY 2 HOUR -- 带起止窗口的周期事件从2024年开始每12小时执行一次到2024年底结束 ON SCHEDULE EVERY 12 HOUR STARTS 2024-01-01 00:00:00 ENDS 2024-12-31 23:59:59MySQL的时间单位很丰富常用的间隔关键字如下间隔单位说明示例YEAR年EVERY 1 YEARMONTH月EVERY 1 MONTHWEEK周EVERY 2 WEEKDAY天EVERY 1 DAYHOUR时EVERY 6 HOURMINUTE分EVERY 15 MINUTESECOND秒EVERY 30 SECONDDAY_HOUR天和小时EVERY 1 2 DAY_HOUR 表示1天2小时HOUR_MINUTE小时和分钟EVERY 1 30 HOUR_MINUTE 表示1小时30分钟MINUTE_SECOND分钟和秒EVERY 1 30 MINUTE_SECOND 表示1分30秒多级单位这种写法在实际业务里用得不多知道有这回事就行。绝大多数场景用EVERY 1 DAY、EVERY 1 HOUR就够了。3.3 事件体内嵌多条语句的正确姿势上面那个例子只有一条SQL所以直接放在DO后面。但如果一个事件要做多件事比如既要更新汇总表又要清理日志那就不能用简单的一句SQL了必须用BEGIN...END包裹成一个复合语句块。这里有一个特别容易踩的坑mysql客户端默认把分号当作语句分隔符你如果在事件体里写了多条带分号的SQL客户端会提前截断导致创建失败。解决方法是先修改语句分隔符DELIMITER // CREATE EVENT ev_nightly_maintenance ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 02:30:00 DO BEGIN DELETE FROM operation_log WHERE created_at NOW() - INTERVAL 90 DAY; UPDATE daily_report_status SET status ready, updated_at NOW() WHERE report_date CURDATE(); END // DELIMITER ;注意DELIMITER //本身不是SQL语句它是mysql客户端的指令所以你在别的图形化工具里执行时不一定支持但在命令行客户端里必须这样写。某些GUI工具中创建复合事件也可能需要换一种输入方式建议用mysql命令行直接执行最稳。3.4 事件的生命周期管理从创建到删除事件建好之后不是只能放着不管它还支持完整的生命周期管理。查看当前库所有事件SHOW EVENTS;查看某个事件的详细定义SHOW CREATE EVENT ev_clean_old_log;临时暂停一个事件又不想删掉定义ALTER EVENT ev_clean_old_log DISABLE;再次启用ALTER EVENT ev_clean_old_log ENABLE;修改事件的调度计划ALTER EVENT ev_clean_old_log ON SCHEDULE EVERY 2 DAY;删除事件DROP EVENT IF EXISTS ev_clean_old_log;这里要额外提一下ON COMPLETION PRESERVE这个选项。默认情况下一次性事件执行完之后会被自动删除。如果你想保留这个事件定义便于以后查看或再次启用可以加上这个子句CREATE EVENT ev_once_clean ON SCHEDULE AT CURRENT_TIMESTAMP INTERVAL 5 MINUTE ON COMPLETION PRESERVE DO DELETE FROM temp_data WHERE status expired;加了ON COMPLETION PRESERVE的事件执行完成后状态会变成DISABLED不会自动删除但也不会再次执行除非你手动修改调度计划或重新启用。4. 一个完整实战案例订单数据每日定时汇总这一节我直接给一个能跑的完整案例我自己在项目中经常这么用。假设你有一张订单流水表每天业务量几十万行产品希望每天早上看到前一天的订单维度汇总包括订单数、销售额、客单价。4.1 先准备两张表一张是业务订单表假设结构简化如下CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL, created_at DATETIME NOT NULL, INDEX idx_created_at (created_at) );一张是汇总结果表CREATE TABLE daily_order_sales ( stat_date DATE PRIMARY KEY, order_count INT NOT NULL DEFAULT 0, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0, avg_amount DECIMAL(10,2) NOT NULL DEFAULT 0, updated_at DATETIME NOT NULL );4.2 创建汇总存储过程和定时事件为了让事件体简单一点我喜欢把复杂逻辑先写进存储过程然后事件里只写一句CALL调用。比如DELIMITER // CREATE PROCEDURE sp_generate_daily_order_sales() BEGIN INSERT INTO daily_order_sales (stat_date, order_count, total_amount, avg_amount, updated_at) SELECT DATE(created_at), COUNT(*), SUM(amount), ROUND(SUM(amount) / COUNT(*), 2), NOW() FROM orders WHERE created_at DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND created_at CURDATE() GROUP BY DATE(created_at) ON DUPLICATE KEY UPDATE order_count VALUES(order_count), total_amount VALUES(total_amount), avg_amount VALUES(avg_amount), updated_at NOW(); END // DELIMITER ;然后创建一个事件每天早上6点调用这个存储过程DELIMITER // CREATE EVENT ev_daily_order_sales ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 06:00:00 ON COMPLETION PRESERVE DO BEGIN CALL sp_generate_daily_order_sales(); END // DELIMITER ;把复杂逻辑放到存储过程里有几个好处一是事件体看起来干净改逻辑时不用改事件二是存储过程可以被手动调用方便你随时在出问题时补数三是存储过程本身还能带日志记录、异常捕获灵活性比直接在事件里写SQL高很多。4.3 开启调度器并验证事件真的跑了如果实例还没打开事件调度器先执行SET GLOBAL event_scheduler ON;想确认效果可以先手动往orders表插入几条昨天的数据然后手动调用一次存储过程看看汇总表是否正常CALL sp_generate_daily_order_sales(); SELECT * FROM daily_order_sales;接着再确认事件本身的状态SHOW EVENTS\G之后可以查询information_schema.EVENTS看事件下一次执行时间SELECT EVENT_NAME, STATUS, EXECUTE_AT, INTERVAL_VALUE, INTERVAL_FIELD, STARTS FROM information_schema.EVENTS WHERE EVENT_SCHEMA 你的库名;等事件真的到点执行完以后检查汇总表里是否多出对应的数据这算是端到端的验证。不要只看到事件状态是ENABLED就认为万事大吉要真正看到业务表里产生了结果才算数。4.4 权限准备与账号建议创建事件需要有EVENT权限执行事件则需要底层SQL涉及表的相关权限所以单独建一个运维账号会更清晰。我通常会这样授权GRANT EVENT, EXECUTE ON mydb.* TO ops_event%; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO ops_event%;不建议直接拿root来建事件也不建议让业务账号顺带拥有事件管理权限。定时任务一旦被别人误改排查成本比省下的那点账号管理功夫高得多。5. 事件没执行按这套排查链路走一遍5.1 第一步查开关状态ON和DISABLED是两回事事件不执行最基础的排查点就是全局开关。先用最简单的语句确认SHOW VARIABLES LIKE event_scheduler;结果如果是OFF那么所有事件都不会执行执行SET GLOBAL event_scheduler ON;即可。但要注意这个设置只对当前实例运行期生效重启后可能回到配置里的默认值所以还是要改配置文件持久化。结果如果是DISABLED那么你很可能是从配置层面禁用了调度器。需要在my.cnf里确认[mysqld]部分没有event_schedulerDISABLED改成ON后重启实例。这个过程当前连接无法动态完成。5.2 第二步查事件本身有没有被禁用或过期全局开关没问题时再检查事件自己的状态。SHOW EVENTS\G重点看Status字段ENABLED表示正常DISABLED表示被手动暂停了。Execute at或Starts字段能看出事件计划是否合理如果发现时间点在很久以前可能是事件没设置周期只在过去执行过一次就结束了。还有一种情况是事件执行过一次之后被自动删除或变成了DISABLED往往是因为建事件时没有加ON COMPLETION PRESERVE一次性事件默认跑完就销毁。这时检查information_schema.EVENTS里还能不能看到这个事件确认是不是被系统自动清理了。5.3 第三步确认权限和错误日志事件即使建成了执行时也可能会遇到权限错误比如事件定义者没有对应表的DELETE权限或者调用的存储过程不存在。因为事件“到点自动跑”的特点这个错误不太容易被业务方感知它会悄悄记在MySQL错误日志里。排查时先看MySQL错误日志通常在数据目录下文件名类似*.err执行tail -f /var/log/mysqld.log然后配合查看是否有类似“Could not execute”或“Event Scheduler”相关的记录。如果错误日志里明确提示权限不足那就对应补权限。也可以从performance_schema的语句事件历史表查看事件有没有真正发起过SQL执行SELECT EVENT_NAME, SQL_TEXT, TIMER_START, ROWS_AFFECTED FROM performance_schema.events_statements_history WHERE EVENT_NAME LIKE %ev_daily_order_sales% ORDER BY TIMER_START DESC LIMIT 10;这里需要performance_schema已开启而且只能看到当前连接生命周期内的部分历史记录能做个辅助参考。5.4 第四步时区、连接数、锁竞争这些隐藏因素事件没跑的排查里时区问题是仅次于权限的第二大坑。我之前遇到过一次事件STARTS设置的是23:30:00但数据库的系统时区是UTC服务器本地时间是东八区结果事件实际触发时间比预期晚了整整8个小时每天跑出来的汇总数据日期都错了。处理方式是在MySQL启动参数或配置里明确时区[mysqld] default-time-zone 08:00或者连接到实例后执行SET GLOBAL time_zone 08:00;改完时区后建议把已有事件重新DISABLE再ENABLE一次让调度器重新计算下一次执行时间。另一类隐藏因素是锁竞争。如果事件执行时目标表正被一个大事务长时间持有行锁或表锁那么事件的SQL会一直在等锁。你看起来事件没执行其实它在后台默默等待。这时候可以在SHOW PROCESSLIST里看到这个事件对应的连接线程State列显示Waiting for table metadata lock或类似状态处理方式就是找到持锁的长事务并评估是否可以终止。5.5 一次真实排查过程复盘有次客户反馈“每日汇总数据连续三天没更新”我上手时先做了这几步事后复盘顺序很明确开关状态、事件状态、错误日志、时区、锁等待基本能把大多数不执行的问题定位到具体环节。6. 进阶避坑存储过程、主从复制与性能取舍6.1 在事件里调用存储过程时最容易栽的跟头事件直接调用存储过程最常见的坑有两个。第一个是分隔符问题。很多新人在创建包含存储过程的复合事件时忘了DELIMITER导致创建语句在客户端被分号切断报出一堆莫名其妙的语法错误。解决办法就是前面说的用DELIMITER //把客户端分隔符临时换掉。第二个是事务边界问题。如果你的存储过程内部包含事务操作要清楚一个过程执行失败时既有的INSERT或UPDATE是否已经提交。比如过程里先插入日志表再更新主表主表更新失败导致异常退出日志表那条记录可能已经被持久化了。做关键数据维护时建议在存储过程里用异常处理机制回滚避免数据处理留一半。我常用的做法是在事件对应的存储过程里加一个日志表记录每次执行的开始和结束状态这样就算SQL本身没报错也能通过日志表排查“为什么数据结果不对”。6.2 主从环境下别让事件跑两遍这是我在生产环境踩过最大的一个坑。刚开始做主从复制时主库建了事件没管从库结果发现从库的数据多了一倍。原因就是主从的MySQL实例各自都开了事件调度器主库的事件执行了一份从库自己的事件又执行了一份。正确的做法是主库开启事件调度器并创建事件从库把事件调度器关掉。事件执行时产生的数据变更会作为普通写入操作通过复制过程同步到从库不需要从库再自己动手跑一遍。-- 从库执行 SET GLOBAL event_scheduler OFF;更稳妥的方式是在从库的配置文件中写死[mysqld] event_schedulerOFF唯一例外是某些特殊场景你希望在从库跑不一样的任务比如从库单独做统计报表但不影响主库。这时可以在从库上创建不同名称的独立事件并且确保这些事件不会在主库上被执行。类似这类需求我的习惯是给事件名称加前缀区分比如slave_开头一眼就知道只能在从库执行避免后续运维误操作。6.3 事件失败怎么发现日志表加错误处理事件是后台自动执行的一旦失败不会有人像调用接口一样收到报错。想让事件执行过程变得可观测一个实用的办法是在事件体里加错误处理逻辑把执行状态写入一张日志表。下面是一个简化版的日志记录事件每5分钟执行一次健康检查并记录每次执行的时间和结果DELIMITER // CREATE EVENT ev_check_heartbeat ON SCHEDULE EVERY 5 MINUTE ON COMPLETION PRESERVE DO BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN INSERT INTO event_log(event_name, status, msg, created_at) VALUES (ev_check_heartbeat, failed, execute failed, NOW()); END; INSERT INTO event_log(event_name, status, msg, created_at) VALUES (ev_check_heartbeat, success, heartbeat ok, NOW()); END // DELIMITER ;加了这个日志表之后每天看一次事件日志表就能知道事件有没有正常执行而不是等业务方发现数据不对才去翻错误日志。6.4 关于备份事件定义与版本差异的经验最后说一个大家容易忽略的运维点事件定义本身需要备份。如果你用mysqldump导数据默认可能不包含事件定义需要显式加参数mysqldump --events --triggers --routines mydb mydb_backup.sql--events这个参数会导出事件定义恢复时也能一并恢复。如果没有这个参数你备份出来的库在另一台机器上虽然数据完整但定时任务全部丢失恢复后整个依赖事件的业务链条可能会悄悄断掉。另外要注意版本差异。老版本里事件定义存在于mysql.event系统表而MySQL 8.0之后系统表结构有变化查询事件统一走information_schema.EVENTS更稳妥。我用8.0建事件的语法和5.7差别不大但建议在从5.7往8.0迁移时把事件定义先导出再导入别直接在升级过程中依赖原地保留那样最保险。从我的个人使用体会来说MySQL事件是个被低估的功能。它学习成本不高却在日常运维里省掉了很多隐形时间。我习惯把所有重复性的、周期性的数据库内事务都交给事件和cron分工合作需要跨系统调用的任务走调度平台纯数据库内部逻辑全部交给事件整体架构清晰了不少。掌握它的核心语法和排障思路之后你大概率会把它列为自己日常工作的标准配置之一。
MySQL事件调度器实战：让定时清理与汇总任务在数据库内部自动运行
凌晨两点手机弹出一条磁盘告警一张三个月没清理的日志表把实例撑到了快满。相信不少搞数据库运维或后端开发的人都经历过这种场景——数据清理、报表汇总、归档删除这些脏活本身不难难的是怎么让它们“按时自动执行”。MySQL事件Event Scheduler就是MySQL内置的定时任务调度器它相当于给数据库装了一个守护进程能按指定时间自动执行SQL语句或存储过程不需要额外装cron、不需要写外部脚本甚至不用依赖应用服务器的操作系统。简单点说事件功能适合所有想让“数据库内部工作自动转起来”的人想定时清理历史数据的DBA、想做每日统计报表的后端、想给业务表做定期归档的架构师都能用它替代一批结构松散的定时脚本。这篇文章我会从实际使用的角度出发讲清楚事件是怎么运转的、怎么建、怎么排障以及我在生产环境里踩过的那些真坑。1. 定时任务落在数据库内部MySQL事件能替你省掉多少事1.1 用cron跑数据库定时任务的三个麻烦很多人一开始处理定时清数、定时汇总第一反应都是“在服务器上写个cron到点跑一段SQL”。这条路看似简单实际用久了麻烦不少。第一是任务脚本散落。脚本文件可能落在某台应用服务器上也可能是某人的个人机器上。数据库一旦迁移、机器一旦重装脚本就跟着失联没人记得那个清理任务在哪台机器上挂着。第二是网络链路不稳定。应用服务器和数据库不在同一个内网时定时脚本连数据库偶尔会碰到防火墙变更、连接超时、掉线重连等问题任务看起来跑了实际可能没执行成功而且很难第一时间发现。第三是多实例扩展时的处理成本高。你从单库拆成主从或者上了多个业务分片每个节点都要单独部署一套cron脚本谁跑过了、谁没跑排查一轮就很费劲。如果把定时任务直接放进MySQL事件里这些问题会被简化不少任务定义就在数据库里跟着数据库走迁移库的时候事件可以一并导出多实例上也只需要在对应实例创建对应事件。而且事件调用的SQL直接走本机连接少了一层网络抖动风险。1.2 MySQL事件调度器是个什么角色MySQL事件本质上是一种“存储在数据库内部的定时程序”。它由事件调度器Event Scheduler统一管理调度器会在后台不断判断当前时间到了哪个事件的下一次执行时间到了就去执行该事件对应的SQL或存储过程。从MySQL 5.1版本开始这个功能就已经内置了到现在依旧是数据库原生定时任务最顺手的一种方案。它的用法和我后面要讲到的存储过程配合得很好事件负责“定时”存储过程负责“做事”两者组合就能实现很多自动化运维动作。用我平时最直白的理解来说事件就是“数据库里的cron”。但它和cron有一个关键区别事件的执行主体是MySQL实例本身它不依赖外部进程也不会因为服务器重启后忘了拉起任务而失效。只要MySQL服务正常起来调度器就会按照事件定义的时间计划继续工作。1.3 哪些场景用事件最合适根据我日常的实践事件特别适合这几类任务定期清理删除过期日志、临时表、历史流水避免数据无限膨胀。定时汇总每天凌晨计算前一天的订单汇总、用户留存、PV/UV这类统计结果。数据归档把冷数据搬运到归档表或者在业务低峰期完成大表分区切换。健康检查定期扫描长期未成交的订单、超时的支付单自动做状态流转。分布式锁释放比如定时释放一些死锁业务留下的资源标记。它不适合的场景也很明确不适合高频率的秒级任务毕竟事件的触发和SQL执行本身有开销秒级甚至毫秒级调度不建议硬塞给数据库也不适合需要调用外部HTTP接口、读写文件系统之类的复杂业务逻辑那种活还是交给消息队列或专门的任务调度框架更合理。2. 事件调度的底层逻辑状态、线程与时间判定2.1 event_scheduler的三种状态先记住一个参数event_scheduler。它有三种取值实际含义差得很远。状态含义能否动态设置ON调度器运行事件按计划执行可以SET GLOBAL event_scheduler ON;OFF调度器未运行事件不执行但事件定义保留可以SET GLOBAL event_scheduler OFF;DISABLED调度器已被禁用事件不执行且无法动态开启不可以必须改配置文件后重启实例这里有一个我见过很多人忽略的坑OFF和DISABLED表面看都是“不执行”但OFF状态还能用SET GLOBAL event_scheduler ON随时打开DISABLED状态是启动时通过[mysqld]配置项或启动参数锁死的它不会因为你在会话里执行SET GLOBAL就改变必须修改配置并重启MySQL才生效。所以生产环境初始化数据库时如果打算用事件功能建议直接把配置写进my.cnf[mysqld] event_schedulerON这样实例每次重启后事件都能自动恢复执行而不是手动去开一遍。不同MySQL版本的默认值有差异有些5.x版本默认是OFF新版本普遍默认ON但不同安装包和发行版的默认配置不一定一致所以别靠默认值自己显式设置最稳。2.2 调度器线程在忙碌什么当你把event_scheduler设置为ON后MySQL内部会启动一个常驻后台线程专门负责事件调度。你在实例上用SHOW PROCESSLIST或者SHOW FULL PROCESSLIST会看到一个名为event_scheduler的线程Command列显示为Daemon这就是它。这个线程的工作方式很像是“闹钟管理员”定期扫描当前库中所有事件的下一次执行时间找出已经到期的事件触发对应的SQL执行。理论上它并不保证严格精确到秒而是周期性扫描所以事件一般不是毫秒级准时的调度器。如果你想依赖事件做“整点零分零秒必须更新缓存”这种强时序逻辑那不是一个好主意。另外要注意调度器线程只负责“发起”执行真正的SQL执行还是交给新建的连接线程。事件执行过程中如果发生卡顿、锁等待影响的是该事件自己的执行进度一般的慢查询不会长时间阻塞调度器线程本身。2.3 事件的时间计划如何计算事件的时间计划由AT和EVERY这类子句决定MySQL会为每个事件记录一个“下一次执行时间”。每次执行完成后如果是周期性事件系统会根据事件的间隔设置自动计算新的下一次执行时间如果是一次性事件执行完事件就结束了。这里涉及到时区问题比如我的服务器系统时区可能是UTC而数据库写入的统计时间是东八区如果事件的STARTS时间写的是2024-01-01 02:00:00那实际触发行为会受MySQL系统时区的影响可能和你想的并不一致。所以强烈建议在创建事件之前先统一确认好实例的系统时区和会话时区否则很容易出现“每天凌晨跑出来的数据是前一天或后一天的”这种诡异问题。3. CREATE EVENT一条语句过关语法拆解和易错点3.1 最基础的建事件语句先看一个最典型、也最常见的例子每天凌晨3点删除180天前的操作日志。CREATE EVENT ev_clean_old_log ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 03:00:00 DO DELETE FROM operation_log WHERE created_at NOW() - INTERVAL 180 DAY;这个语句结构拆开看ev_clean_old_log事件名称一台实例里建议全局唯一方便排查。ON SCHEDULE EVERY 1 DAY表示周期性执行间隔为1天。STARTS 2024-01-01 03:00:00表示从哪天开始生效。DO DELETE FROM ...事件触发时执行的SQL语句。如果你希望事件创建后立刻开始计时也可以把STARTS省略那么默认创建后就会开始计算执行周期。另外STARTS可以写成CURRENT_TIMESTAMP INTERVAL 1 HOUR这种相对时间形式兼容性更好一些。3.2 ON SCHEDULE的三种计划写法与时间单位事件的调度计划有三种基础写法覆盖绝大多数需求-- 一次性事件10分钟后执行一次 ON SCHEDULE AT CURRENT_TIMESTAMP INTERVAL 10 MINUTE -- 周期性事件每2小时执行一次 ON SCHEDULE EVERY 2 HOUR -- 带起止窗口的周期事件从2024年开始每12小时执行一次到2024年底结束 ON SCHEDULE EVERY 12 HOUR STARTS 2024-01-01 00:00:00 ENDS 2024-12-31 23:59:59MySQL的时间单位很丰富常用的间隔关键字如下间隔单位说明示例YEAR年EVERY 1 YEARMONTH月EVERY 1 MONTHWEEK周EVERY 2 WEEKDAY天EVERY 1 DAYHOUR时EVERY 6 HOURMINUTE分EVERY 15 MINUTESECOND秒EVERY 30 SECONDDAY_HOUR天和小时EVERY 1 2 DAY_HOUR 表示1天2小时HOUR_MINUTE小时和分钟EVERY 1 30 HOUR_MINUTE 表示1小时30分钟MINUTE_SECOND分钟和秒EVERY 1 30 MINUTE_SECOND 表示1分30秒多级单位这种写法在实际业务里用得不多知道有这回事就行。绝大多数场景用EVERY 1 DAY、EVERY 1 HOUR就够了。3.3 事件体内嵌多条语句的正确姿势上面那个例子只有一条SQL所以直接放在DO后面。但如果一个事件要做多件事比如既要更新汇总表又要清理日志那就不能用简单的一句SQL了必须用BEGIN...END包裹成一个复合语句块。这里有一个特别容易踩的坑mysql客户端默认把分号当作语句分隔符你如果在事件体里写了多条带分号的SQL客户端会提前截断导致创建失败。解决方法是先修改语句分隔符DELIMITER // CREATE EVENT ev_nightly_maintenance ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 02:30:00 DO BEGIN DELETE FROM operation_log WHERE created_at NOW() - INTERVAL 90 DAY; UPDATE daily_report_status SET status ready, updated_at NOW() WHERE report_date CURDATE(); END // DELIMITER ;注意DELIMITER //本身不是SQL语句它是mysql客户端的指令所以你在别的图形化工具里执行时不一定支持但在命令行客户端里必须这样写。某些GUI工具中创建复合事件也可能需要换一种输入方式建议用mysql命令行直接执行最稳。3.4 事件的生命周期管理从创建到删除事件建好之后不是只能放着不管它还支持完整的生命周期管理。查看当前库所有事件SHOW EVENTS;查看某个事件的详细定义SHOW CREATE EVENT ev_clean_old_log;临时暂停一个事件又不想删掉定义ALTER EVENT ev_clean_old_log DISABLE;再次启用ALTER EVENT ev_clean_old_log ENABLE;修改事件的调度计划ALTER EVENT ev_clean_old_log ON SCHEDULE EVERY 2 DAY;删除事件DROP EVENT IF EXISTS ev_clean_old_log;这里要额外提一下ON COMPLETION PRESERVE这个选项。默认情况下一次性事件执行完之后会被自动删除。如果你想保留这个事件定义便于以后查看或再次启用可以加上这个子句CREATE EVENT ev_once_clean ON SCHEDULE AT CURRENT_TIMESTAMP INTERVAL 5 MINUTE ON COMPLETION PRESERVE DO DELETE FROM temp_data WHERE status expired;加了ON COMPLETION PRESERVE的事件执行完成后状态会变成DISABLED不会自动删除但也不会再次执行除非你手动修改调度计划或重新启用。4. 一个完整实战案例订单数据每日定时汇总这一节我直接给一个能跑的完整案例我自己在项目中经常这么用。假设你有一张订单流水表每天业务量几十万行产品希望每天早上看到前一天的订单维度汇总包括订单数、销售额、客单价。4.1 先准备两张表一张是业务订单表假设结构简化如下CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL, created_at DATETIME NOT NULL, INDEX idx_created_at (created_at) );一张是汇总结果表CREATE TABLE daily_order_sales ( stat_date DATE PRIMARY KEY, order_count INT NOT NULL DEFAULT 0, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0, avg_amount DECIMAL(10,2) NOT NULL DEFAULT 0, updated_at DATETIME NOT NULL );4.2 创建汇总存储过程和定时事件为了让事件体简单一点我喜欢把复杂逻辑先写进存储过程然后事件里只写一句CALL调用。比如DELIMITER // CREATE PROCEDURE sp_generate_daily_order_sales() BEGIN INSERT INTO daily_order_sales (stat_date, order_count, total_amount, avg_amount, updated_at) SELECT DATE(created_at), COUNT(*), SUM(amount), ROUND(SUM(amount) / COUNT(*), 2), NOW() FROM orders WHERE created_at DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND created_at CURDATE() GROUP BY DATE(created_at) ON DUPLICATE KEY UPDATE order_count VALUES(order_count), total_amount VALUES(total_amount), avg_amount VALUES(avg_amount), updated_at NOW(); END // DELIMITER ;然后创建一个事件每天早上6点调用这个存储过程DELIMITER // CREATE EVENT ev_daily_order_sales ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 06:00:00 ON COMPLETION PRESERVE DO BEGIN CALL sp_generate_daily_order_sales(); END // DELIMITER ;把复杂逻辑放到存储过程里有几个好处一是事件体看起来干净改逻辑时不用改事件二是存储过程可以被手动调用方便你随时在出问题时补数三是存储过程本身还能带日志记录、异常捕获灵活性比直接在事件里写SQL高很多。4.3 开启调度器并验证事件真的跑了如果实例还没打开事件调度器先执行SET GLOBAL event_scheduler ON;想确认效果可以先手动往orders表插入几条昨天的数据然后手动调用一次存储过程看看汇总表是否正常CALL sp_generate_daily_order_sales(); SELECT * FROM daily_order_sales;接着再确认事件本身的状态SHOW EVENTS\G之后可以查询information_schema.EVENTS看事件下一次执行时间SELECT EVENT_NAME, STATUS, EXECUTE_AT, INTERVAL_VALUE, INTERVAL_FIELD, STARTS FROM information_schema.EVENTS WHERE EVENT_SCHEMA 你的库名;等事件真的到点执行完以后检查汇总表里是否多出对应的数据这算是端到端的验证。不要只看到事件状态是ENABLED就认为万事大吉要真正看到业务表里产生了结果才算数。4.4 权限准备与账号建议创建事件需要有EVENT权限执行事件则需要底层SQL涉及表的相关权限所以单独建一个运维账号会更清晰。我通常会这样授权GRANT EVENT, EXECUTE ON mydb.* TO ops_event%; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO ops_event%;不建议直接拿root来建事件也不建议让业务账号顺带拥有事件管理权限。定时任务一旦被别人误改排查成本比省下的那点账号管理功夫高得多。5. 事件没执行按这套排查链路走一遍5.1 第一步查开关状态ON和DISABLED是两回事事件不执行最基础的排查点就是全局开关。先用最简单的语句确认SHOW VARIABLES LIKE event_scheduler;结果如果是OFF那么所有事件都不会执行执行SET GLOBAL event_scheduler ON;即可。但要注意这个设置只对当前实例运行期生效重启后可能回到配置里的默认值所以还是要改配置文件持久化。结果如果是DISABLED那么你很可能是从配置层面禁用了调度器。需要在my.cnf里确认[mysqld]部分没有event_schedulerDISABLED改成ON后重启实例。这个过程当前连接无法动态完成。5.2 第二步查事件本身有没有被禁用或过期全局开关没问题时再检查事件自己的状态。SHOW EVENTS\G重点看Status字段ENABLED表示正常DISABLED表示被手动暂停了。Execute at或Starts字段能看出事件计划是否合理如果发现时间点在很久以前可能是事件没设置周期只在过去执行过一次就结束了。还有一种情况是事件执行过一次之后被自动删除或变成了DISABLED往往是因为建事件时没有加ON COMPLETION PRESERVE一次性事件默认跑完就销毁。这时检查information_schema.EVENTS里还能不能看到这个事件确认是不是被系统自动清理了。5.3 第三步确认权限和错误日志事件即使建成了执行时也可能会遇到权限错误比如事件定义者没有对应表的DELETE权限或者调用的存储过程不存在。因为事件“到点自动跑”的特点这个错误不太容易被业务方感知它会悄悄记在MySQL错误日志里。排查时先看MySQL错误日志通常在数据目录下文件名类似*.err执行tail -f /var/log/mysqld.log然后配合查看是否有类似“Could not execute”或“Event Scheduler”相关的记录。如果错误日志里明确提示权限不足那就对应补权限。也可以从performance_schema的语句事件历史表查看事件有没有真正发起过SQL执行SELECT EVENT_NAME, SQL_TEXT, TIMER_START, ROWS_AFFECTED FROM performance_schema.events_statements_history WHERE EVENT_NAME LIKE %ev_daily_order_sales% ORDER BY TIMER_START DESC LIMIT 10;这里需要performance_schema已开启而且只能看到当前连接生命周期内的部分历史记录能做个辅助参考。5.4 第四步时区、连接数、锁竞争这些隐藏因素事件没跑的排查里时区问题是仅次于权限的第二大坑。我之前遇到过一次事件STARTS设置的是23:30:00但数据库的系统时区是UTC服务器本地时间是东八区结果事件实际触发时间比预期晚了整整8个小时每天跑出来的汇总数据日期都错了。处理方式是在MySQL启动参数或配置里明确时区[mysqld] default-time-zone 08:00或者连接到实例后执行SET GLOBAL time_zone 08:00;改完时区后建议把已有事件重新DISABLE再ENABLE一次让调度器重新计算下一次执行时间。另一类隐藏因素是锁竞争。如果事件执行时目标表正被一个大事务长时间持有行锁或表锁那么事件的SQL会一直在等锁。你看起来事件没执行其实它在后台默默等待。这时候可以在SHOW PROCESSLIST里看到这个事件对应的连接线程State列显示Waiting for table metadata lock或类似状态处理方式就是找到持锁的长事务并评估是否可以终止。5.5 一次真实排查过程复盘有次客户反馈“每日汇总数据连续三天没更新”我上手时先做了这几步事后复盘顺序很明确开关状态、事件状态、错误日志、时区、锁等待基本能把大多数不执行的问题定位到具体环节。6. 进阶避坑存储过程、主从复制与性能取舍6.1 在事件里调用存储过程时最容易栽的跟头事件直接调用存储过程最常见的坑有两个。第一个是分隔符问题。很多新人在创建包含存储过程的复合事件时忘了DELIMITER导致创建语句在客户端被分号切断报出一堆莫名其妙的语法错误。解决办法就是前面说的用DELIMITER //把客户端分隔符临时换掉。第二个是事务边界问题。如果你的存储过程内部包含事务操作要清楚一个过程执行失败时既有的INSERT或UPDATE是否已经提交。比如过程里先插入日志表再更新主表主表更新失败导致异常退出日志表那条记录可能已经被持久化了。做关键数据维护时建议在存储过程里用异常处理机制回滚避免数据处理留一半。我常用的做法是在事件对应的存储过程里加一个日志表记录每次执行的开始和结束状态这样就算SQL本身没报错也能通过日志表排查“为什么数据结果不对”。6.2 主从环境下别让事件跑两遍这是我在生产环境踩过最大的一个坑。刚开始做主从复制时主库建了事件没管从库结果发现从库的数据多了一倍。原因就是主从的MySQL实例各自都开了事件调度器主库的事件执行了一份从库自己的事件又执行了一份。正确的做法是主库开启事件调度器并创建事件从库把事件调度器关掉。事件执行时产生的数据变更会作为普通写入操作通过复制过程同步到从库不需要从库再自己动手跑一遍。-- 从库执行 SET GLOBAL event_scheduler OFF;更稳妥的方式是在从库的配置文件中写死[mysqld] event_schedulerOFF唯一例外是某些特殊场景你希望在从库跑不一样的任务比如从库单独做统计报表但不影响主库。这时可以在从库上创建不同名称的独立事件并且确保这些事件不会在主库上被执行。类似这类需求我的习惯是给事件名称加前缀区分比如slave_开头一眼就知道只能在从库执行避免后续运维误操作。6.3 事件失败怎么发现日志表加错误处理事件是后台自动执行的一旦失败不会有人像调用接口一样收到报错。想让事件执行过程变得可观测一个实用的办法是在事件体里加错误处理逻辑把执行状态写入一张日志表。下面是一个简化版的日志记录事件每5分钟执行一次健康检查并记录每次执行的时间和结果DELIMITER // CREATE EVENT ev_check_heartbeat ON SCHEDULE EVERY 5 MINUTE ON COMPLETION PRESERVE DO BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN INSERT INTO event_log(event_name, status, msg, created_at) VALUES (ev_check_heartbeat, failed, execute failed, NOW()); END; INSERT INTO event_log(event_name, status, msg, created_at) VALUES (ev_check_heartbeat, success, heartbeat ok, NOW()); END // DELIMITER ;加了这个日志表之后每天看一次事件日志表就能知道事件有没有正常执行而不是等业务方发现数据不对才去翻错误日志。6.4 关于备份事件定义与版本差异的经验最后说一个大家容易忽略的运维点事件定义本身需要备份。如果你用mysqldump导数据默认可能不包含事件定义需要显式加参数mysqldump --events --triggers --routines mydb mydb_backup.sql--events这个参数会导出事件定义恢复时也能一并恢复。如果没有这个参数你备份出来的库在另一台机器上虽然数据完整但定时任务全部丢失恢复后整个依赖事件的业务链条可能会悄悄断掉。另外要注意版本差异。老版本里事件定义存在于mysql.event系统表而MySQL 8.0之后系统表结构有变化查询事件统一走information_schema.EVENTS更稳妥。我用8.0建事件的语法和5.7差别不大但建议在从5.7往8.0迁移时把事件定义先导出再导入别直接在升级过程中依赖原地保留那样最保险。从我的个人使用体会来说MySQL事件是个被低估的功能。它学习成本不高却在日常运维里省掉了很多隐形时间。我习惯把所有重复性的、周期性的数据库内事务都交给事件和cron分工合作需要跨系统调用的任务走调度平台纯数据库内部逻辑全部交给事件整体架构清晰了不少。掌握它的核心语法和排障思路之后你大概率会把它列为自己日常工作的标准配置之一。
