能，但必须确认 mysql 服务开启了 event_scheduler；默认为 off，需通过 set global event_scheduler = on 临时开启或在 my.cnf 中配置 event_scheduler = on 并重启生效。
MySQL Event 能否替代应用层定时清理？
能，但必须确认 MySQL 服务开启了 event_scheduler。默认它是 OFF 的，不手动打开，建了 Event 也永远不会执行。别被 CREATE EVENT 成功迷惑——那只是语法校验通过，调度器没开，Event 就是死的。
检查方式：
SHOW VARIABLES LIKE 'event_scheduler';如果返回
OFF 或 DISABLED，得立刻改：- 临时开启（重启失效）：
SET GLOBAL event_scheduler = ON;
- 永久生效：在
my.cnf的[mysqld]段落加一行event_scheduler = ON，然后重启 MySQL
写一个安全删除日志表的 Event 示例
假设日志表叫 operation_log，有个时间字段 created_at，要删 30 天前的数据。别直接 DELETE FROM ... WHERE created_at ——大表可能锁表、阻塞写入、甚至触发 long query kill。
更稳妥的做法是分批删 + 加索引保障：
- 确保
created_at有索引（ALTER TABLE operation_log ADD INDEX idx_created_at (created_at);） - 用
LIMIT控制单次删除量，比如每次删 1000 行：DELETE FROM operation_log WHERE created_at
- Event 定义里必须显式写上
ON SCHEDULE EVERY 1 DAY，不能只写EVERY 1 DAY STARTS '2024-01-01 02:00:00'却漏掉EVERY，否则它只执行一次
完整 Event 创建语句示例：
CREATE EVENT cleanup_old_logs ON SCHEDULE EVERY 1 DAY STARTS DATE_ADD(DATE(NOW()), INTERVAL 1 DAY) + INTERVAL 2 HOUR DO DELETE FROM operation_log WHERE created_at <h3>为什么 Event 执行后查不到日志或没效果？</h3><p>常见原因不是 SQL 写错，而是权限和作用域问题：</p>
- 创建 Event 的用户必须有
EVENT权限（GRANT EVENT ON *.* TO 'user'@'%';），仅SELECT/DELETE不够 - Event 默认在创建时的数据库下运行，如果
operation_log在admin_db库，但你在test_db里建 Event，就得写全名：DELETE FROM admin_db.operation_log ... - 查看 Event 是否启用、上次执行时间：
SELECT * FROM information_schema.EVENTS WHERE EVENT_NAME = 'cleanup_old_logs';
关注STATUS（应为ENABLED）和LAST_EXECUTED - 错误日志不进 MySQL general log，得查 error log —— 如果 Event 里 SQL 报错（比如字段不存在），只会静默失败，除非你手动加
GET DIAGNOSTICS或把逻辑包进存储过程里捕获异常
比 Event 更稳的日志清理方案是什么？
对高写入、大数据量日志表（比如每天千万级插入），Event + DELETE 仍是权衡后的常用选择，但它本质是“软删”，会留下碎片、膨胀 ibdata1。真正干净的做法是按时间分区（PARTITION BY RANGE (TO_DAYS(created_at))），然后用 ALTER TABLE ... DROP PARTITION —— 这是瞬时操作，不走 DML，无锁无日志压力。不过分区需要建表时设计，存量大表在线重分区代价很高，所以多数场景还是先用 Event 控制节奏，等下次重构再切分区。
另外提醒一句：EVENT 不支持跨实例同步，主从复制中它只在主库定义并执行；从库不会自动创建同名 Event，也不会执行主库 Event 触发的 DELETE —— 所以从库日志不会被清理，得单独处理。
