官网文档：MySQL :: MySQL 8.4 Reference Manual :: 27.4.1 Event Scheduler Overview

一 引入

MySQL 的 Event Scheduler（事件调度器）功能首次在 MySQL 5.1 中引入，旨在让用户能够在数据库中定义和管理计划任务。它类似于操作系统中的任务调度工具（如 Cron），但在 MySQL 中运行，主要用来自动执行周期性的任务或在特定时间点运行一次的任务。

二 作用

Event Scheduler 的主要作用是 自动化数据库操作，包括但不限于：

1. 定时清理数据：如清除过期的会话数据或日志。
2. 周期性数据汇总：定时生成统计报告或汇总表。
3. 维护任务：如重建索引或更新缓存表。
4. 业务逻辑实现：实现特定的时间触发事件（如发送提醒或通知）。

它的优势在于任务直接运行在数据库内，不需要额外依赖外部脚本或调度工具。

---

三 使用方法

1. 启用事件调度器

默认情况下，MySQL 的 Event Scheduler 是关闭的。可以通过以下方式开启：

• 临时启用（仅当前会话有效）：

  SET GLOBAL event_scheduler = ON; 

• 配置永久启用： 编辑 MySQL 配置文件（my.cnf），添加以下内容：

  [mysqld] 
  event_scheduler=ON 

2. 创建事件

MySQL 中通过 CREATE EVENT 语句来创建事件。

• 创建一个在指定时间运行一次的事件：

  CREATE EVENT example_event 
  ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY 
  DO 
  INSERT INTO example_table (message, created_at) 
  VALUES ('Hello, Event!', NOW()); 

• 创建一个周期性运行的事件：

  CREATE EVENT clean_up_logs 
  ON SCHEDULE EVERY 1 DAY 
  STARTS '2025-01-15 00:00:00' 
  DO 
  DELETE 
  FROM logs 
  WHERE created_at < NOW() - INTERVAL 30 DAY; 

3. 查询事件

查看当前数据库中定义的事件：

SELECT * 
FROM INFORMATION_SCHEMA.EVENTS 
WHERE EVENT_SCHEMA = 'your_database_name'; 

4. 修改事件

通过 ALTER EVENT 修改事件：

ALTER EVENT clean_up_logs 
ON SCHEDULE EVERY 2 DAY; 

5. 删除事件

通过 DROP EVENT 删除事件：

DROP EVENT IF EXISTS example_event; 

---

四 详细示例

以下是一个更完整的使用场景示例：

场景：公司需要每日凌晨自动清理过期会话，同时每周统计用户活跃数据。

1. 清理过期会话：

   CREATE EVENT delete_expired_sessions 
   ON SCHEDULE EVERY 1 DAY 
   STARTS '2025-01-15 00:00:00' 
   DO 
   DELETE FROM user_sessions WHERE expired = 1; 

2. 每周统计用户活跃数据：

   CREATE EVENT weekly_user_statistics 
   ON SCHEDULE EVERY 1 WEEK 
   STARTS '2025-01-15 02:00:00' 
   DO 
   INSERT INTO user_statistics (week_start, active_users) 
   SELECT DATE(NOW() - INTERVAL 1 WEEK) AS week_start, COUNT(*) AS active_users 
   FROM users 
   WHERE last_login >= NOW() - INTERVAL 1 WEEK; 

---

五 使用时的注意事项

1. 权限问题：

   • 创建事件需要 EVENT 权限，检查权限：

     SHOW GRANTS FOR 'user'@'host'; 

2. 性能影响：

   • 复杂或频繁触发的事件可能对数据库性能产生负面影响。应避免事件操作长时间锁定表。

3. 时间同步：

   • Event Scheduler 依赖服务器时间，如果时间配置不准确（如未正确设置时区），可能导致事件触发错误。

4. 备份与恢复：

   • 事件定义存储在 INFORMATION_SCHEMA.EVENTS 中，确保备份恢复策略包括事件的重新部署。

---

六 相关功能及其区别

功能	作用	使用场景
Event Scheduler	定时运行 SQL 任务	定期维护数据库、数据清理、周期性数据分析
触发器 (Trigger)	响应表中的增删改操作	业务逻辑强关联的实时任务，如日志记录
存储过程 (Procedure)	封装复用的业务逻辑	执行复杂业务逻辑或多步骤操作
视图 (View)	动态查询结果的逻辑表示	简化复杂查询，增强数据访问的安全性
外部任务调度 (如 Cron)	数据库外的调度工具	数据库外部任务调度（跨系统、跨数据库操作）

     区别与使用场景

1. Event Scheduler vs. Cron：

   • Event Scheduler：内置于 MySQL，适用于数据库内部的自动化任务。
   • Cron：更强大，适合管理跨系统任务。

2. Event Scheduler vs. Trigger：

   • Event Scheduler：基于时间触发，适用于定时任务。
   • Trigger：基于表操作触发，适用于实时响应任务。

3. Event Scheduler vs. Procedure：

   • Event Scheduler：主要作用是定时调用 SQL 操作。
   • Procedure：封装可复用的业务逻辑，事件和外部程序均可调用。

---

七 总结

MySQL Event Scheduler 是一个强大的内置工具，适合处理周期性任务或时间触发任务。然而，需要注意性能优化、权限配置以及任务的复杂度管理。如果你的场景涉及跨系统或复杂逻辑，可以结合其他工具（如 Cron、触发器、存储过程）一起使用以达到更好的效果。

---

八 补充：停机时段的 Event 怎么办

在 MySQL 中，Event Scheduler 的行为依赖于事件的定义和数据库的状态。对于停机期间未能执行的事件，其行为取决于事件的调度类型（ON SCHEDULE）以及事件是否启用了“捕获遗漏”功能。

默认行为

1. 单次事件（AT 定时事件）：

   • 如果事件定义为在某个具体时间点（如 ON SCHEDULE AT '2025-01-15 08:00:00'）执行，而在该时间点数据库关闭，事件将被跳过，永远不会再执行。

2. 周期性事件（EVERY 定时事件）：

   • 周期性事件不会追溯执行停机期间的错过时间点。它只会从数据库重新启动并启用事件调度器后，等待下一次触发时间来执行。
   • 例如：

     CREATE EVENT daily_task 
     ON SCHEDULE EVERY 1 DAY 
     STARTS '2025-01-14 08:00:00' 
     DO 
     DELETE FROM logs WHERE created_at < NOW() - INTERVAL 30 DAY; 

     如果数据库在 8:00 停机，10:00 启动，那么当天的任务不会执行，事件将在次日 8:00 执行。

---

捕获遗漏功能（ON COMPLETION NOT PRESERVE）

MySQL 没有直接内置的“捕获遗漏任务”功能。换句话说，MySQL 不会检查事件是否在某个时间被跳过并追溯执行。但可以通过以下方式模拟此行为：

解决方案 1：使用事件逻辑自行检查未执行的时间点

通过在事件中实现检查逻辑，可以手动追溯未执行的任务。例如：

CREATE EVENT check_and_execute_missed_tasks 
ON SCHEDULE EVERY 1 DAY 
STARTS '2025-01-15 08:00:00' 
DO 
BEGIN 
    -- 检查是否有未处理的任务 
    IF NOT EXISTS (SELECT 1 FROM task_log WHERE task_date = CURDATE() - INTERVAL 1 DAY) 
    THEN 
        -- 执行任务 
        DELETE FROM logs WHERE created_at < NOW() - INTERVAL 30 DAY; 
        -- 记录任务已执行 
        INSERT INTO task_log (task_date, status) VALUES (CURDATE() - INTERVAL 1 DAY, 'Executed'); 
    END IF; 
END; 

解决方案 2：在数据库重启后，手动检查并触发补偿

• 在系统启动时执行补偿任务：

  ALL execute_missed_tasks(); 

• 存储过程示例：

  DELIMITER $$ 
  CREATE PROCEDURE execute_missed_tasks() 
  BEGIN 
      DECLARE last_run_date DATE; 
      SET last_run_date = (SELECT MAX(task_date) FROM task_log); 
  
      WHILE last_run_date < CURDATE() DO 
          -- 执行补偿逻辑 
          DELETE FROM logs WHERE created_at < last_run_date - INTERVAL 30 DAY; 
          -- 记录补偿任务 
          INSERT INTO task_log (task_date, status) VALUES (last_run_date, 'Compensated'); 
          SET last_run_date = last_run_date + INTERVAL 1 DAY; 
      END WHILE; 
  END $$ 
  DELIMITER ; 

解决方案 3：结合外部调度工具

如果业务需要强一致性，建议配合外部工具（如 Cron 或 Scheduler Framework）来管理错过的事件。

---

其他注意事项

1. 确保 Event Scheduler 启用：

   • 如果 MySQL 在重新启动后，event_scheduler 未启用，事件将不会执行。需要确保其状态为 ON：

     SET GLOBAL event_scheduler = ON; 

2. 检查事件状态：

   • 查看是否有事件被禁用或未正常执行：

     SELECT EVENT_NAME, STATUS, LAST_EXECUTED 
     FROM INFORMATION_SCHEMA.EVENTS; 

3. 记录日志：

   • 为了跟踪事件执行情况，可以在事件中插入日志，便于分析错过的执行：

     INSERT INTO event_log (event_name, executed_at, status) 
     VALUES ('daily_task', NOW(), 'Success'); 

---

总结

• 停机期间未执行的事件不会自动补偿。
• 对于重要任务，可在事件逻辑中加入补偿机制，或者结合外部调度工具。
• 定期监控事件状态和执行日志，确保任务按预期执行。

---

---

---