MySQL EVENT定时任务易因调度器关闭、权限不足、锁表或时间表达式错误而静默失败；须先确认event_scheduler=ON，周期任务用EVERY单数单位，STARTS用CURRENT_TIMESTAMP，DELETE须带WHERE+LIMIT且字段有索引。
EVENT 是 MySQL 原生支持的定时任务机制，但直接用它删数据极易出事——不是语法错，而是调度器没开、权限不够、语句锁表、时间表达式失效这些隐性问题，导致事件静默失败或业务卡死。
确认 event_scheduler 已开启，否则 CREATE EVENT 必定失败
几乎所有“创建事件报错”的根本原因，就是 event_scheduler 处于 OFF 状态。错误提示常是误导性的，比如 ERROR 1547: Event execution time is in the past，其实跟时间无关。
- 先查状态：
SHOW VARIABLES LIKE 'event_scheduler';—— 返回OFF就得处理 - 临时启用（重启失效）：
SET GLOBAL event_scheduler = ON; - 永久启用（生产必须）：在
my.cnf的[mysqld]段加event_scheduler = ON，然后重启 MySQL - 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用该变量，此时
EVENT不可用，只能改用外部定时调用CALL
CREATE EVENT 里 ON SCHEDULE 的写法陷阱
ON SCHEDULE 决定事件何时执行，写错就等于没设——尤其是周期任务误用 AT，或单位用了复数。
- 周期任务必须用
EVERY：EVERY 1 DAY✅，EVERY 1 DAYS❌（单位必须单数） - 想“从现在起 1 小时后首次执行，之后每小时一次”：
EVERY 1 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 1 HOUR - 别用
NOW()做STARTS或事件体里的动态时间基准：NOW()在事件定义时刻就被固化，CURRENT_TIMESTAMP才会在每次触发时实时求值 -
AT只适合一次性任务，比如AT '2026-06-01 02:00:00'，清理类长期任务不能用
DELETE 语句必须带 WHERE + LIMIT，且 created_at 要有索引
直接 DELETE FROM logs WHERE create_time 看似简洁，但在百万级表上会瞬间锁死写入。
-
WHERE条件漏写、字段名拼错、类型不匹配（比如用VARCHAR存时间），会导致全表扫描+全表锁定 - 必须加
LIMIT控制单次影响行数：DELETE FROM logs WHERE create_time -
create_time字段必须有索引（B-tree类型），否则LIMIT也救不了全表扫描 - 更安全的做法是把
DELETE封装进存储过程，里面加循环、延时、计数校验，避免一次删太多 - 别用
TRUNCATE：它不走事务、无法按条件删、且会重置自增 ID
事件创建后查不到？注意默认数据库上下文
SHOW EVENTS; 默认只显示当前 USE 的数据库下的事件。如果没切换库，就看不到任何结果。
- 先指定库：
USE your_db_name;，再执行SHOW EVENTS; - 跨库查看：
SHOW EVENTS FROM your_db_name;或查系统表：SELECT * FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'your_db_name'; - 事件状态为
DISABLED表示被手动停用，需用ALTER EVENT xxx ENABLE;激活 - 失败日志不输出到客户端，而写进 MySQL 的
error.log，排查静默失败必须翻它
实际运行中，最常被忽略的是：事件体里用 NOW() 导致时间逻辑漂移、created_at 没索引却删大表、以及云环境里根本没法开 event_scheduler 这三点。
