在MySQL中如何使用存储过程实现自动化任务？-mysql教程-PHP中文网

mysql需启用event_scheduler并显式启用event才能自动执行存储过程；event不支持日历语义调度，须用starts固化时间；默认not preserve且新建为disable，需手动enable并设on completion preserve。

在mysql中如何使用存储过程实现自动化任务？

MySQL 本身不支持“自动执行存储过程”这个动作，必须显式启用事件调度器（event_scheduler），再用 EVENT 绑定调用，否则存储过程永远只等你手动 CALL。

必须先打开 `event_scheduler`，否则所有 `EVENT` 都是摆设

MySQL 默认关闭事件调度器，哪怕你建好了 EVENT，它也不会跑。这不是权限问题，是全局开关没开。

检查状态：SHOW VARIABLES LIKE 'event_scheduler'; —— 返回 OFF 就还没开
临时开启（重启失效）：SET GLOBAL event_scheduler = ON;
永久生效：必须在 my.cnf 或 my.ini 的 [mysqld] 段落里加一行：event_scheduler = ON，然后重启 MySQL
注意：普通用户无法执行 SET GLOBAL，需要 SUPER 权限；应用部署时别只写临时命令，漏掉配置文件修改会导致上线后定时任务静默失效

`CREATE EVENT` 的时间定义容易写错，特别是年/月/周逻辑

EVERY 只支持固定间隔（如每5分钟、每1天），不支持“每月1号”或“每周日23点”这种日历语义——它没有 Cron 表达式解析能力。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

想每天凌晨执行：ON SCHEDULE EVERY 1 DAY STARTS '2026-07-03 00:00:00'（注意 STARTS 必须是未来时间，否则事件创建后立即触发一次）
想每年1月1日执行：ON SCHEDULE EVERY 1 YEAR STARTS '2027-01-01 00:00:00'，不能用 CURDATE() 动态算，因为 STARTS 值在创建时就固化了
错误示范：EVERY 1 MONTH 不等于“每月1号”，而是从创建时刻起，每30天左右触发一次（按秒数算），可能漂移到每月2号、3号
真正要按日历跑，得用 STARTS + ENDS + 多个事件组合，或者干脆换外部调度器（如 Linux cron 调 mysql -e "CALL my_proc()"）

`EVENT` 和存储过程共用事务，但 `EVENT` 自身不支持事务控制

事件触发后，DO CALL my_proc() 是在事件上下文中执行的，如果存储过程里有 COMMIT 或 ROLLBACK，会直接影响整个事件事务；而事件本身无法加 START TRANSACTION。

存储过程内部若含 DROP TABLE、CREATE TEMPORARY TABLE 等隐式提交语句，会导致后续语句不在同一事务中——这和你手调 CALL 的行为一致，但容易在定时场景下被忽略
ON COMPLETION PRESERVE 很关键：默认是 NOT PRESERVE，意味着事件执行完一次就自动删除。日常维护任务必须显式加上 ON COMPLETION PRESERVE，否则第二天就失效了
调试时别只看 information_schema.EVENTS 中的 LAST_EXECUTED，还要查对应表数据是否真被修改——因为事件可能成功触发、但存储过程内部出错被静默吞掉（比如没写 DECLARE EXIT HANDLER）