应使用 DELETE ... WHERE 配合时间条件直接清理，而非存储过程；MySQL 无内置自动清理，稳定做法是将 DELETE 语句交由外部调度器（如 cron）执行，确保可控、可查、可重试。
用 DELETE ... WHERE 配合时间条件直接删，别用存储过程硬扛
MySQL 没有内置的“自动清理任务”，所谓定期清理，本质就是定时执行一条带时间判断的 DELETE 语句。很多人一上来就想写存储过程+事件调度器，结果发现事件在从库不触发、时间精度不准、错误难排查——纯属给自己加戏。
真正稳定的做法是：把清理逻辑写成一条清晰的 DELETE，交给外部调度器（如 Linux cron 或运维平台）调用 mysql -e 执行。这样可控、可查、可重试。
WHERE created_at 是最常用的时间筛选写法，注意别用 <code>BETWEEN或字符串拼接，容易出时区或索引失效问题- 务必确认
created_at字段上有索引，否则全表扫描一次可能锁表几十秒，业务直接受影响 - 单次删除别超过 10 万行，大表建议分批，比如加
LIMIT 5000并循环执行，避免事务日志暴涨和锁等待
为什么不能直接 TRUNCATE TABLE？
TRUNCATE TABLE 快是快，但它会重置自增 ID、清空全文索引、且无法加 WHERE 条件——它不是“清理过期数据”，而是“一键归零”。除非你确定要清空整张表，否则用它就等于误操作。
-
TRUNCATE是 DDL 操作，在事务中不可回滚，出错没法补救 - 如果表被其他表外键引用，默认会报错，得先关外键检查（
SET FOREIGN_KEY_CHECKS = 0），这又引入额外风险 - 某些云数据库（如阿里云 RDS）对
TRUNCATE有更严权限控制，开发账号可能根本执行不了
EVENT 能用，但默认是关闭的，而且有坑
MySQL 原生支持 EVENT，看起来很“自动”，但实际线上敢开的人不多。因为它的开关、权限、时区、错误静默等行为太容易踩雷。
- 必须先执行
SET GLOBAL event_scheduler = ON，重启后失效，还得写进配置文件my.cnf的[mysqld]段落里 -
EVENT默认用系统时区，如果应用用的是Asia/Shanghai，而 MySQL 服务端时区是 UTC，那设定的“每天凌晨2点”就变成凌晨10点执行 - 执行失败不会报警，日志里只有一行
ERROR 1051 (42S02): Unknown table这类模糊提示，很难定位是 SQL 写错了还是表名变了
删完记得优化，但别迷信 OPTIMIZE TABLE
大批量删除后，InnoDB 表的空间不会自动还给操作系统，只是标记为“可复用”。这时候要不要 OPTIMIZE TABLE？看情况。
- 如果后续写入压力不大、磁盘空间充足，跳过它。因为
OPTIMIZE TABLE会重建整张表，期间锁表，小表无所谓，大表可能卡住业务 - 如果用的是 MySQL 5.7+ 且启用了
innodb_file_per_table=ON（默认），删完后可以考虑ALTER TABLE t ENGINE=InnoDB，效果类似但更可控 - 更轻量的做法是监控
data_free值（查INFORMATION_SCHEMA.TABLES），只有当它持续占表总大小 30% 以上，再考虑整理
真正麻烦的不是怎么删，而是删之前没确认好保留策略——比如日志表按天分区了，却还在用 WHERE 删除，完全浪费了分区剪枝能力；或者时间字段是 VARCHAR 存的 "2023-01-01"，导致索引失效。这些细节比语法本身更容易让清理任务失控。
