数据库定时任务：EVENT 与外部 cron 的取舍

定期清理过期数据、每天凌晨归档历史表，这类活 MySQL 自带的 EVENT 和系统 crontab 都能干。选哪个的关键差异不在功能，在运维视角：出问题时，你在哪一层看得见它。 EVENT 的优势与局限 EVENT 是数据库内部的定时器，建一个： CREATE EVENT ev_clean ON SCHEDULE EVERY 1 DAY DO DELETE FROM logs WHERE created < NOW() - INTERVAL 90 DAY; 优点：跟着库走，不依赖外部机器；逻辑和库在同一处，交接省事。局限也实在：前提是 event_scheduler=ON，这个调度器默认关闭，不少人建了事件压根没在跑；执行过程没有独立日志，成败只能靠数据反推；换库、迁移时容易漏带。还有一个容易踩的点：EVENT 里 NOW() 这类时间函数跟着会话时区走，改过时区的实例要核对触发时间是否符合预期。 外部 cron 的优势 crontab 一行： 0 3 * * * mysql --defaults-extra-file=/etc/mysql/job.cnf -h 10.0.0.5 -u clean_job -e "DELETE FROM logs WHERE created < NOW() - INTERVAL 90 DAY" 优点：执行记录进系统日志，跑没跑、几点跑的一目了然；失败可以接邮件或告警；任务脚本进版本库，跟着发布流程走；以后换数据库，脚本稍改就能复用。代价是多一台执行机要管，密码放进独立的受限配置文件（权限 600），注意 defaults-extra-file 必须写成第一个参数。分钟级的高频任务 cron 也能做，但日志量和告警噪音要先想清楚，别把巡检群刷了屏。 运维可见性是关键差异 排查"数据为什么没清理"时，EVENT 的答案藏在数据库内部，cron 的答案在系统日志里。后者对运维更友好：所有定时任务在一个地方统一看，不用数据库、服务器两头登。任务数量越多的团队，这个差距越大。 结论 单机小项目、任务一两个且纯 SQL 能表达，EVENT 够用，记得把调度器打开。生产环境、任务会持续增多、需要告警和版本管理的，用外部 cron 加专用低权限账号。把定时任务放在数据库外面管，是更经得起审计的做法。无论选哪边，任务都要有执行记录可查，这是底线。