MySQL Event Scheduler 默认关闭，需先启用并授予权限；缓存表清理应避免空窗期，推荐双表切换；事件须加错误捕获与日志；跨版本注意 DEFINER 兼容性。
MySQL Event Scheduler 没启用，CREATE EVENT 直接报错
默认 MySQL 关闭了事件调度器，执行 CREATE EVENT 会提示 ERROR 1541: Event scheduler is disabled。不打开它，后面所有操作都无效。
实操建议：
- 先检查状态：
SHOW VARIABLES LIKE 'event_scheduler';—— 返回OFF就得开 - 临时开启（重启失效）：
SET GLOBAL event_scheduler = ON; - 永久生效：在
my.cnf或my.ini的[mysqld]下加一行：event_scheduler = ON，然后重启 MySQL - 注意权限：
EVENT权限需授予用户，例如：GRANT EVENT ON *.* TO 'your_user'@'%';
清理缓存表时误删正在被查询的数据
很多“缓存表”其实是业务中高频读取的中间结果，比如 cache_user_summary。直接 TRUNCATE TABLE 或 DELETE FROM 可能导致查询中途读到空或部分缺失数据。
实操建议：
- 优先用
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE替代清空 + 全量重刷，避免空窗期 - 如果必须清空，用
TRUNCATE TABLE（比DELETE快且不走事务日志），但确保该表无外键引用、无活跃事务持有锁 - 更稳妥的做法是双表切换：
RENAME TABLE cache_table TO cache_table_old, cache_table_new TO cache_table;，再异步删旧表 - 别在高峰期跑清理事件，用
AT TIMESTAMP或EVERY 1 DAY STARTS '2024-06-01 03:00:00'错开业务高峰
Event 执行失败却没报错，数据越积越多
MySQL Event 默认静默失败，即使 SQL 报错（如字段不存在、权限不足），事件仍标记为“已执行”，SHOW EVENTS 看不到异常，但缓存根本没清掉。
实操建议：
- 务必在事件体里加错误捕获逻辑，例如用
BEGIN ... DECLARE EXIT HANDLER FOR SQLEXCEPTION记录日志到一张event_log表 - 定期查
information_schema.EVENTS中的LAST_EXECUTED和STATUS字段，DISABLED或长时间没更新就出问题了 - 避免在事件里调用存储过程却不检查返回值；函数内异常不会自动传播到事件层
- 测试阶段在事件开头加
INSERT INTO debug_log VALUES (NOW(), 'event_start');，确认它真被触发了
跨版本兼容性：MySQL 5.7 和 8.0 的 DEFINER 行为差异
MySQL 8.0 默认开启 sql_require_primary_key，且对 DEFINER 用户要求更严——如果事件定义里写了 DEFINER = 'admin'@'localhost'，而该用户不存在或权限不足，事件会创建失败或执行时报 Access denied。
实操建议：
- 创建事件时不显式写
DEFINER，让 MySQL 自动设为当前用户（前提是当前用户有EVENT权限） - 若必须指定
DEFINER，确保该用户存在、密码有效、且有对应库表的SELECT/DELETE/INSERT权限 - MySQL 8.0+ 建议用
CREATE OR REPLACE EVENT替代反复删建，避免因DEFINER不一致导致权限校验失败 - 导出事件时用
mysqldump --events，但导入前确认目标实例的DEFINER用户已存在
真正难的不是写一条 CREATE EVENT，而是让清理动作稳定、可观测、不影响业务查询。尤其当缓存表被多个服务共享时，删表时机和锁粒度比语法本身重要得多。
