先说结论：MySQL 确实没有类似 cron 的外部定时功能，但内置的 EVENT 机制可以胜任数据库级别的定时任务——更新过期订单、清理临时数据这类简单场景足够用。前提是你得把 event_scheduler 打开，否则创建事件会直接报错“Event scheduler is not enabled”，或者事件看上去建好了，却一动不动。
MySQL 里没有原生定时任务，得靠事件调度器
EVENT 本质是数据库级的定时触发器，按指定时间间隔自动执行 SQL。版本要求 MySQL ≥ 5.1，而且 event_scheduler 这个系统变量必须设为 ON。很多人踩的第一个坑就是：默认它是 OFF 的。
怎么检查？一行命令搞定：SHOW VARIABLES LIKE 'event_scheduler';，返回 ON 才算数。如果返回 OFF，临时开启可以用 SET GLOBAL event_scheduler = ON;（重启后失效）。要永久生效，得在 my.cnf 配置文件中加上 event_scheduler=ON，然后重启 MySQL。另外别忘了权限：给操作用户授予 EVENT 权限，否则建事件时你会遇到 ERROR 1227 (42000)。
写一个更新过期记录的 EVENT 示例
假设有一张 orders 表，status 字段标记订单状态为 'pending'，created_at 是下单时间。需求很典型：每 5 分钟跑一次，把超过 30 分钟还没处理的订单自动标记为 'expired'。事件写出来就是下面这样：
CREATE EVENT expire_pending_orders
ON SCHEDULE EVERY 5 MINUTE
DO
UPDATE orders
SET status = 'expired'
WHERE status = 'pending'
AND created_at < NOW() - INTERVAL 30 MINUTE;
这里有几个关键点容易忽略：
EVERY 5 MINUTE的意思是“每 5 分钟触发一次”，不是“延迟 5 分钟执行”。它会严格按时间点轮询，比如 10:00、10:05、10:10……NOW() - INTERVAL 30 MINUTE用的是 MySQL 服务器当前时间，每次执行都动态计算，不是事件创建时的固定值。- WHERE 条件一定要加上
status = 'pending'，否则已经标记为 expired 的记录可能被重复更新（虽然 SET 成相同值不报错，但浪费性能）。 - 如果表数据量大，建议在 status 和 created_at 上建联合索引：
INDEX idx_status_created (status, created_at)，避免全表扫描拖垮性能。
PostgreSQL 或 SQLite 用户别硬套 EVENT
PostgreSQL 没有等价的 EVENT 功能，得靠外部调度（比如 pg_cron 扩展或者系统 cron 调 psql）。SQLite 更彻底——连定时能力都没有，只能由应用层轮询或外部触发。硬把上面的 MySQL 语法搬到其他数据库上，会直接报错 syntax error near 'EVENT'。
如果你用的是云数据库（比如阿里云 RDS、AWS RDS），还要确认是否允许开启事件调度器。部分托管服务默认禁用这个功能，或者对 EVENT 权限有限制，得去控制台手动开启，甚至要提工单申请。
真正容易被忽略的是时间精度和事务边界。MySQL EVENT 是在自己的事务中执行的，不会自动加全表锁，但并发高、UPDATE 影响行数多的时候，锁等待可能导致下一轮执行延迟。别指望它做到毫秒级精准，也别把它当成替代应用层调度的万能方案——它就是数据库级别的“小闹钟”，最适合那些周期性的、简单的 SQL 操作。
