必须先启用 event_scheduler，否则 create event 必然失败；检查用 show variables like 'event_scheduler'；临时开启用 set global event_scheduler = on；永久生效需在 my.cnf 中配置并重启；云数据库通常禁用，需改用 crond 调用；create event 必须指定 starts current_timestamp + interval 和 enable；on completion preserve 防止事件被清理；delete 操作须封装进存储过程。
必须先确认 event_scheduler 是否启用，否则 CREATE EVENT 一定失败——这不是语法问题，是服务没开。
检查 event_scheduler 状态是否为 ON
直接查变量值最可靠：
SHOW VARIABLES LIKE 'event_scheduler';
返回 OFF 就说明调度器没启动。常见错误是以为 SQL 写对了就能跑，结果 CREATE EVENT 报错 ERROR 1547 或 ERROR 1541，根源就在这儿。
- 临时开启（MySQL 重启后失效）：
SET GLOBAL event_scheduler = ON; - 永久生效：在
my.cnf的[mysqld]段加一行event_scheduler = ON，然后重启 MySQL - 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用该变量，此时
CREATE EVENT会直接被拒绝，只能改用外部 crond +mysql -e "CALL clean_old_logs()"
CREATE EVENT 必须带 STARTS 和 ENABLE，且时间用 CURRENT_TIMESTAMP
STARTS NOW() 是陷阱：它取的是语句执行那一刻的时间戳，不是事件实际触发时的实时时间。比如你晚上 8 点创建一个“每天凌晨执行”的事件，STARTS NOW() + INTERVAL 1 DAY 会固定在明天 8 点，而不是每天 0 点。
- 正确写法：
STARTS CURRENT_TIMESTAMP + INTERVAL 1 DAY（首次执行时间），配合EVERY 1 DAY才能真正每天零点跑 - 别漏掉
ENABLE——默认新建事件是DISABLED状态，不手动启用就不会执行 -
ON COMPLETION PRESERVE建议加上，避免事件定义被自动清理掉，尤其当清理逻辑需要长期维护时
DELETE 操作必须封装进存储过程，不能直接写在 DO 后面
直接在 DO 里写 DELETE FROM log_table WHERE created_at 是高危操作：没有 LIMIT、没有 SLEEP、没索引支撑，容易锁表、拖垮业务。
- 必须用存储过程封装清理逻辑，例如
CALL clean_old_logs() - 过程内强制分批：
DELETE FROM log_table WHERE created_at - 每次删完加
DO SLEEP(0.1)，让出 CPU 和 IO 资源 -
created_at字段必须有索引，否则LIMIT也救不了全表扫描 - 别用
TRUNCATE替代——它不能带条件，也不走事务，无法按时间范围清理
事件静默失败，必须自己加错误捕获和日志
MySQL EVENT 默认失败不报错：字段名写错、权限不足、表不存在……事件仍显示“已执行”，SHOW EVENTS 看不到异常，但数据越积越多。
- 存储过程中必须声明异常处理器：
DECLARE EXIT HANDLER FOR SQLEXCEPTION - 捕获后至少插入一条日志到专用表（如
cleanup_log），记录错误时间和 SQLSTATE - 清理前加预查：
SELECT COUNT(*) INTO @cnt FROM log_table WHERE created_at ，为 0 就直接 <code>LEAVE，避免空跑 -
ON COMPLETION PRESERVE不代表任务一定成功，只控制事件定义是否保留
真正难的不是写个 CREATE EVENT，而是让清理既安全又稳定：分批、限速、校验、日志、兜底。云环境还得多一层判断——调度器开不开得看厂商，不是你说了算。
