MySQL触发器无法实现定期清理，因其仅响应INSERT、UPDATE、DELETE等DML事件，无时间调度能力；定期清理应使用Event Scheduler，需先启用（SET GLOBAL event_scheduler = ON或配置文件设event_scheduler = ON），再创建定时事件。
MySQL触发器不能实现定期数据清理
触发器只响应 INSERT、UPDATE、DELETE 等表级 DML 事件，它没有时间维度——不支持“每天凌晨执行”“每小时检查一次”这类调度逻辑。想靠 CREATE TRIGGER 实现定时清理，根本走不通。
真正能做定期清理的是 MySQL Event Scheduler
MySQL 自带的事件调度器（Event Scheduler）才是正确工具，它类似操作系统的 cron，可按时间表达式自动执行 SQL。但默认是关闭的，必须手动启用：
- 确认是否开启：
SHOW VARIABLES LIKE 'event_scheduler';—— 返回OFF就得开 - 临时开启（重启失效）：
SET GLOBAL event_scheduler = ON; - 永久生效：在
my.cnf或my.ini中添加event_scheduler = ON - 创建一个每天删 30 天前日志的事件：
CREATE EVENT clean_old_logs ON SCHEDULE EVERY 1 DAY DO DELETE FROM log_table WHERE created_at < NOW() - INTERVAL 30 DAY;
注意：EVENT 需要 EVENT 权限，不是所有账号默认拥有；且事件定义里不能调用存储函数以外的外部程序。
用触发器“伪定时”的常见误用和风险
有人试图在插入时检查时间并顺手清理，比如在 INSERT 触发器里加 DELETE ... WHERE created_at 。这看似“顺便清理”，实际问题很多：
- 每次插入都触发清理，高并发下可能引发锁表或慢查询，
INSERT变得不可预测 - 清理逻辑和业务逻辑耦合，违反单一职责——触发器该管“数据变更约束”，不该管“运维任务”
- 如果清理条件写错（比如漏了
WHERE），可能误删全表，而触发器执行无交互确认 -
TRIGGER中不能包含COMMIT或显式事务控制，遇到大范围删除容易撑爆 undo log
生产环境定期清理更推荐的组合方案
单纯依赖 MySQL 内置事件在复杂场景下仍不够灵活，尤其涉及跨库、归档、通知或失败重试时：
- 轻量级场景：用
EVENT+DELETE或TRUNCATE PARTITION（如果表已分区） - 需要归档：改用外部脚本（Python/Shell），先
INSERT INTO archive_table SELECT ...，再DELETE，便于加日志和监控 - 避免长事务阻塞：清理语句拆成小批量，例如每次删 1000 行，用
WHERE id BETWEEN ? AND ?循环执行 - 别忘了加索引：
DELETE条件字段（如created_at）必须有索引，否则全表扫描会拖垮线上服务
最常被忽略的一点：事件调度器本身不记录执行日志。出问题时你不知道它有没有跑、哪次失败了——得自己在事件体里写 INSERT INTO cleanup_log 或对接外部监控。
