MySQL EVENT未执行的主因是全局调度器默认关闭，需SET GLOBAL event_scheduler=ON或配置my.cnf；常见状态为OFF或SLAVESIDE_DISABLED，且EVERY时间单位仅支持内置枚举值，STARTS/ENDS仅接受秒级datetime字面量。
EVENT 为什么没按预期执行
MySQL 的 EVENT 默认被禁用，即使建好了也不会跑。必须先打开全局开关：SET GLOBAL event_scheduler = ON;。很多运维同学在测试环境开了，上线后忘了配，或者被初始化脚本重置为 OFF —— 查看状态只用 SHOW VARIABLES LIKE 'event_scheduler';，别只看 SHOW EVENTS; 的输出。
常见错误现象：STATUS 显示 SLAVESIDE_DISABLED（主从复制下从库默认禁用），或直接是 OFF；LAST_EXECUTED 为空且 STATUS 是 DISABLED。
- 配置建议：写入
my.cnf的[mysqld]段落，加一行event_scheduler=ON，避免重启后失效 - 权限要求：创建者需有
EVENT权限，不是CREATE ROUTINE或EXECUTE - 时区注意：
EVENT使用 MySQL 服务器时区（@@system_time_zone），不随会话TIMESTAMP变，跨时区部署时务必确认
ON SCHEDULE EVERY 后面的时间单位陷阱
EVERY 不支持自然语言（比如 EVERY 1 DAY 是对的，但 EVERY 24 HOURS 语法错误），且单位必须是 MySQL 内置枚举值：SECOND、MINUTE、HOUR、DAY、WEEK、MONTH、YEAR。想每 90 分钟执行？不能写 EVERY 90 MINUTE，得换算成 EVERY 5400 SECOND。
更隐蔽的问题是 STARTS 和 ENDS 的时间精度：它们只接受到秒级，且必须是合法的 datetime 字面量（如 '2025-04-01 02:00:00'），不能带毫秒或时区偏移。
- 避免用 NOW() 或函数做
STARTS，它只在 CREATE EVENT 时求值一次，不是每次调度都重算 - 如果需要“每天凌晨 2 点”，别写
EVERY 1 DAY STARTS '2025-04-01 02:00:00'—— 这实际是固定间隔 24 小时，第一次在指定时间，第二次是 +24h，第三次还是 +24h，不会自动对齐每天 2 点；正确做法是用AT TIMESTAMP '2025-04-01 02:00:00' + INTERVAL 1 DAY配合DO块里判断逻辑，或改用外部调度器 -
EVERY 1 WEEK从STARTS时间起算，不是从周日/周一自动对齐
EVENT 中调用存储过程 vs 直接写 SQL 的取舍
在 DO 子句里直接写多条 SQL（用分号分隔）看似简单，但一旦出错就难定位——MySQL 不报具体哪行失败，LAST_EXECUTED 为空，STATUS 变成 DISABLED，且无法捕获异常。而封装进存储过程后，能用 DECLARE HANDLER 捕获 SQLSTATE，记录日志，甚至发告警。
性能上无本质差异，但可维护性差太多：修改逻辑要 DROP + CREATE 整个 EVENT，而改存储过程只需 ALTER PROCEDURE。
- 强烈建议所有非单条 INSERT/UPDATE 的
EVENT都封装进存储过程 - 存储过程里避免长事务：
EVENT执行期间若阻塞，后续调度会被跳过（除非设了ON COMPLETION PRESERVE且没被 disable） - 不要在
DO里写SELECT输出结果集——EVENT没客户端，会直接报错中断
查看和调试 EVENT 的真实状态
别只信 SHOW EVENTS;。它只显示元信息，不反映运行时健康度。INFORMATION_SCHEMA.EVENTS 表里的 LAST_EXECUTED 和 STATUS 才是关键指标，但要注意：这个字段更新有延迟，尤其高负载时可能滞后几秒；而且一旦执行中崩溃，STATUS 不会自动变回 ENABLED，得手动 ALTER EVENT ... ENABLE。
最可靠的方式是让 EVENT 自己写日志：在存储过程中插入一条到日志表，带上 NOW() 和执行结果码；或者用 SIGNAL 抛出自定义错误，配合 MySQL 错误日志（需开启 log_error_verbosity=3）。
- 检查是否被自动 disable：查
INFORMATION_SCHEMA.EVENTS的STATUS字段，值为SLAVESIDE_DISABLED表示从库策略限制，不是 bug - 临时禁用用
ALTER EVENT xxx DISABLE，别用DROP，否则丢失调度历史 - 日志表记得加索引：至少在
event_name和exec_time上建联合索引，不然查慢
复杂点在于事件之间可能有依赖或资源竞争，比如两个 EVENT 同时写同一张汇总表，没加锁就会丢数据。这种场景下，靠 EVENT 自身机制很难兜底，得在业务逻辑里处理。
