电商产品预约场景下如何自动删除MySQL表中满3天及以上的指定记录

首先前置准备：你的reserve_products表必须提前包含记录预约发起时间的字段，作为过期判断的核心依据，建议建表时加上：

`reserve_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '用户发起预约的时间'

同时给这个字段加普通索引，避免后续清理操作触发全表扫描锁表：

ALTER TABLE reserve_products ADD INDEX idx_reserve_time (reserve_time);

方案1：MySQL原生事件调度器（零额外组件，适合中小规模站点） #

这是最直接不需要引入外部依赖的实现方式，步骤如下：

1. 先检查数据库的事件调度器开关状态，执行：

   SHOW VARIABLES LIKE 'event_scheduler';
   

   如果返回值为OFF，可以临时执行SET GLOBAL event_scheduler = ON;开启，永久生效需要在数据库配置文件中添加event_scheduler=ON后重启服务。
2. 创建定时清理事件，根据业务量选择合适的执行规则：
   • 如果预约数据量不大，选每小时执行一次的规则：

     CREATE EVENT IF NOT EXISTS ev_clean_expired_reserve
     ON SCHEDULE EVERY 1 HOUR
     STARTS CURRENT_TIMESTAMP
     ON COMPLETION PRESERVE
     COMMENT '自动删除存储满3天的无效预约记录'
     DO
       -- 分批删除避免单次删太多造成长事务锁表
       REPEAT
         DELETE FROM reserve_products 
         WHERE reserve_time < (NOW() - INTERVAL 3 DAY)
         LIMIT 1000;
       UNTIL ROW_COUNT() = 0 END REPEAT;
     

   • 如果站点业务压力集中在白天，可以调整为低峰期固定执行，比如每天凌晨3点跑一次：
     把上面的调度规则段改成ON SCHEDULE EVERY 1 DAY STARTS CURRENT_DATE + INTERVAL 3 HOUR，对线上业务的影响会更小。

方案2：分区表DROP分区清理（适合百万级以上大表高并发场景） #

如果reserve_products表单表数据量超过百万，每次DELETE操作都会产生大量binlog、触发索引碎片化，性能开销很高，这时候可以按预约时间做RANGE分区，通过直接DROP过期分区的方式完成清理——这个操作是元数据级别的修改，几乎瞬时完成，不会产生锁表影响。
示例配置：

-- 把表改造为按3天粒度的RANGE分区
ALTER TABLE reserve_products
PARTITION BY RANGE (TO_DAYS(reserve_time)) (
  PARTITION p_before_3d VALUES LESS THAN (TO_DAYS(CURDATE() - INTERVAL 3 DAY)),
  PARTITION p_recent VALUES LESS THAN MAXVALUE
);

后续配套的定时逻辑只需要每次执行时，把日期早于3天的分区直接DROP即可，性能远高于逐行DELETE。注意这个方案需要同步做一个配套的定时任务，提前创建未来时间的分区，避免所有数据落到默认的MAXVALUE分区里。

方案3：应用层定时任务兜底（适合数据库权限管控严格的场景） #

如果数据库权限不允许开启事件调度器，就可以在电商站点自身的任务调度模块（比如分布式任务调度框架、应用内嵌定时任务）中添加清理逻辑，低峰期执行同样的过期记录删除。这个方案的额外优势是可以在清理时同步完成业务侧的善后，比如释放预约占用的库存、给用户发送预约过期提醒，灵活性比数据库层操作更高。

关键注意事项 #

• 清理操作不要执行得过于频繁，比如每分钟扫描一次表，就算没有可删除的记录，也会产生不必要的磁盘IO开销，建议最低执行间隔不低于1小时
• 单次删除一定要加LIMIT分批，避免一次删除几万条记录造成长事务，阻塞正常的预约读写请求
• 不要依赖操作系统级的CRON脚本直连数据库做清理，一旦脚本异常、网络中断，清理逻辑就会中断，也没有事务一致性保障

内容的提问来源于stack exchange，提问作者Usman Shafiq