触发器不能替代定时清理，它只在DML操作时被动执行，属“懒清理”；EVENT才是MySQL中实现精准周期性清理的正确机制，支持定时、重试与日志追踪。
触发器不能替代定时清理，它只响应DML操作
MySQL触发器本身不具备“自动按时间删除”的能力——它不会自己跑，只在INSERT、UPDATE、DELETE发生时被动执行。所谓“自动删除”，其实是借了业务写入的“顺风车”：比如每次插入新日志，就顺手删掉30天前的老数据。但这不是真正的定时任务，而是一种“懒清理”策略。
- 如果表长期没写入（比如归档库），触发器永远不会触发，过期数据就一直躺着
- 高频写入场景下，每次
INSERT都触发全表扫描删旧数据，可能拖慢写入性能 - 无法精准控制执行时机（例如必须凌晨2点删），也不支持失败重试或日志追踪
用EVENT才能真正实现生命周期管理
MySQL的EVENT才是专为周期性任务设计的机制，相当于数据库内置的cron。它不依赖业务操作，能严格按设定时间（如每天02:00）执行DELETE或TRUNCATE，是做数据生命周期管理（如保留最近7天日志）的正确姿势。
- 必须先确认
event_scheduler已开启：SET GLOBAL event_scheduler = ON - 推荐用
DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY)而非NOW() - INTERVAL 7 DAY，避免跨天时区/精度偏差 - 首次创建后，用
SHOW EVENTS检查状态，注意STATUS列是否为ENABLED
触发器+EVENT组合使用更稳妥
纯EVENT适合批量清理，但无法保证“写入即生效”的强一致性；纯触发器又不可靠。实际项目中，常把两者结合：用触发器做即时兜底（比如插入时强制校验并清理超限行），再用EVENT做每日兜底巡检（确保没人写入时也能清掉残留）。
- 例如日志表：触发器限制单次插入后最多存1万条，EVENT每天凌晨再按时间维度删一次
- 注意触发器里别调用
SELECT或复杂子查询，容易锁表；EVENT里的DELETE建议加LIMIT分批删，防长事务 - 测试阶段务必用
SELECT先验证WHERE条件，比如SELECT COUNT(*) FROM logs WHERE log_time
重启MySQL后EVENT会失效，必须持久化配置
很多线上事故源于这个细节：SET GLOBAL event_scheduler = ON只是会话级生效，MySQL服务重启后自动变回OFF，所有EVENT停止运行——数据就开始悄悄堆积。
- 永久生效需修改MySQL配置文件（如
my.cnf），在[mysqld]段加入event_scheduler=ON - 容器化部署时，要在启动脚本或initContainer里显式执行
SET GLOBAL命令 - 监控告警建议加上：定期查
information_schema.EVENTS，确认关键EVENT的LAST_EXECUTED是否在合理时间范围内
触发器和EVENT不是二选一，而是分工关系：一个管“有没有人动”，一个管“时间到了没”。漏掉后者，等于把数据寿命交给运气。
