目录一、前置准备 风险评估必做1. 数据与表结构摸底2. 备份底线3. 环境隔离与权限二、核心方案分批限流删除主流最优方案零业务影响方案思路1. 关键参数设计通用参考2. 具体 SQL 逻辑基于自增主键 id 时间1基础分页删除推荐最稳定2纯时间分页无自增主键用订单号 / 索引3. 执行载体三种选择按架构选方式 1Shell 脚本 MySQL 客户端运维常用简单无侵入方式 2Java/Python 后台程序业务侧可控可加熔断方式 3数据库定时事件不推荐三、进阶优化高并发 / 大集群必备1. 主从架构专项处理2. 大表优化先归档再删除超千万级终极方案3. 禁止行为红线四、分阶段执行节奏3000 万条参考耗时五、监控 应急兜底1. 实时监控指标2. 应急方案六、删除后收尾工作七、长期方案避免再次出现大表总结最简落地版快速复述核心原则禁止直接DELETE大批量数据、避开业务高峰、分批删除、限流、锁最小化、兜底回滚、全程监控适配 MySQL 常规架构分前置评估→分批删除执行→收尾优化三阶段。一、前置准备 风险评估必做1. 数据与表结构摸底确认时间字段依赖create_time/order_time作为删除条件确保该字段建有单列索引无索引会全表扫严重堵库。表信息引擎默认 InnoDB、是否有主键必须有自增 ID / 订单号主键分批依据主键、有无外键、触发器、关联业务视图 / 定时任务。业务口径确认「1 年前数据」时间边界核对 3000 万条数据量级避免误删有效数据。流量评估区分业务低峰期凌晨 00:00–06:00 优先执行记录日常 QPS、CPU、磁盘 IO 阈值。2. 备份底线方式 1优先物理备份xtrabackup整表 / 整库备份速度快、不锁业务。方式 2逻辑备份历史数据单独导出 1 年前数据备份后再删除满足合规溯源。禁止删除完成后再备份。3. 环境隔离与权限线上主库禁止手动直连大批量操作通过后台脚本 / 定时任务执行读写分离架构优先在从库做数据校验、预演再到主库执行。二、核心方案分批限流删除主流最优方案零业务影响方案思路利用主键 时间范围分页小批量删除每次只删少量行控制事务大小、行锁范围、IO 压力循环执行全程不阻塞线上读写。为什么不用DELETE FROM 表 WHERE 时间xxx 大批量 DELETE 会长事务、大量 undo 日志、行锁范围大、主从延迟飙升、IO 打满、线上查询超时。1. 关键参数设计通用参考单批次删除行数每次 100~500 行根据数据库性能微调高配库最大不超 1000批次间隔50~200ms限流削峰 IO、主从延迟执行窗口仅凌晨低峰运行白天停止规避业务流量。2. 具体 SQL 逻辑基于自增主键 id 时间1基础分页删除推荐最稳定-- 循环执行直到无满足条件数据 DELETE FROM order_table WHERE create_time 2025-06-07 00:00:00 AND id ? LIMIT 500; -- 单批行数执行逻辑记录上一轮最大id避免重复扫描全表每次只删 500 条短事务、锁范围极小每执行一轮sleep 100ms限流。2纯时间分页无自增主键用订单号 / 索引DELETE FROM order_table WHERE create_time 2025-06-07 00:00:00 ORDER BY create_time ASC LIMIT 500;3. 执行载体三种选择按架构选方式 1Shell 脚本 MySQL 客户端运维常用简单无侵入配合while循环 休眠低峰定时执行示例逻辑# 伪逻辑循环删除每次500条间隔100ms while true; do affected$(mysql -e DELETE FROM order_table WHERE create_time 2025-06-07 LIMIT 500; | wc -l) if [ $affected -eq 0 ]; then break; fi sleep 0.1 # 限流 done方式 2Java/Python 后台程序业务侧可控可加熔断增加开关、暂停 / 终止接口突发业务上涨可立刻停删监控数据库指标CPU/IO/ 主从延迟超标自动休眠记录执行日志、已删除条数便于对账。方式 3数据库定时事件不推荐仅纯运维库使用线上业务库禁用异常难以紧急终止。三、进阶优化高并发 / 大集群必备1. 主从架构专项处理主库分批删除从库会同步 binlog必然产生主从延迟监控从库延迟延迟 3s 自动加大sleep间隔或临时暂停严禁在延迟过高时继续执行。2. 大表优化先归档再删除超千万级终极方案如果该订单表日常查询极频繁单纯分批删除仍有 IO 压力采用归档分离新建归档表order_history_archive结构和原表一致分批迁移历史数据INSERT ... SELECT LIMIT到归档表迁移完成后再分批删除原表数据归档表可冷备份、下线、迁移至低成本存储OSS / 冷数据库。优势原表频繁访问的热数据完全不受影响IO 压力拆分。3. 禁止行为红线不执行DELETE 不带 LIMIT全量删除不执行TRUNCATE清空全表锁表、丢数据、无法回滚不在业务高峰、大促、报表时段执行不关闭 binlog主从集群会数据不一致不一次性加大批次量1000 行风险陡增。四、分阶段执行节奏3000 万条参考耗时以每批 500 行、间隔 100ms计算总批次60000 轮纯执行 休眠耗时约 1.67 小时结合人为停顿、指标监控分 2~3 个凌晨窗口跑完不单日一次性跑完留缓冲。第一晚试运行删 100 万条观察 CPU、IO、主从延迟、线上接口响应第二晚批量执行大部分数据第三晚收尾清理剩余数据。五、监控 应急兜底1. 实时监控指标数据库CPU、内存、磁盘 IO、连接数、慢查询、主从延迟 业务接口响应时间、报错率、QPS。2. 应急方案线上业务异常立刻停止删除脚本 / 程序无需回滚分批删除可断点续跑误删数据依赖前置备份恢复出现死锁 / 锁等待调小单批行数、加大休眠间隔。六、删除后收尾工作表空间回收InnoDB 大批量删除后会产生碎片数据文件不自动缩小。低峰执行ALTER TABLE order_table FORCE;或 轻量重建表根据碎片率选择碎片率高建议分批做完删除后择机做表重建优化查询性能。统计核对比对删除前后数据量确认 3000 万历史数据清理完成归档数据处置归档表定期冷备按需下线。七、长期方案避免再次出现大表表分区按时间分区月 / 年分区后续清理历史数据直接DROP PARTITION毫秒级完成无 IO 压力冷热数据分离热订单存主库N 个月前数据自动归档至历史库定时清理配置月度小批量清理任务避免数据堆积到千万级。总结最简落地版快速复述先全量备份核对时间条件与索引凌晨低峰执行主键 LIMIT 小批量删除500 行 / 批批次间休眠限流全程监控数据库与业务指标异常立即暂停清理完成后整理表碎片长期改用时间分区表根治大表清理问题。
5000 万订单表清理 3000 万历史数据（不影响线上）落地方案
目录一、前置准备 风险评估必做1. 数据与表结构摸底2. 备份底线3. 环境隔离与权限二、核心方案分批限流删除主流最优方案零业务影响方案思路1. 关键参数设计通用参考2. 具体 SQL 逻辑基于自增主键 id 时间1基础分页删除推荐最稳定2纯时间分页无自增主键用订单号 / 索引3. 执行载体三种选择按架构选方式 1Shell 脚本 MySQL 客户端运维常用简单无侵入方式 2Java/Python 后台程序业务侧可控可加熔断方式 3数据库定时事件不推荐三、进阶优化高并发 / 大集群必备1. 主从架构专项处理2. 大表优化先归档再删除超千万级终极方案3. 禁止行为红线四、分阶段执行节奏3000 万条参考耗时五、监控 应急兜底1. 实时监控指标2. 应急方案六、删除后收尾工作七、长期方案避免再次出现大表总结最简落地版快速复述核心原则禁止直接DELETE大批量数据、避开业务高峰、分批删除、限流、锁最小化、兜底回滚、全程监控适配 MySQL 常规架构分前置评估→分批删除执行→收尾优化三阶段。一、前置准备 风险评估必做1. 数据与表结构摸底确认时间字段依赖create_time/order_time作为删除条件确保该字段建有单列索引无索引会全表扫严重堵库。表信息引擎默认 InnoDB、是否有主键必须有自增 ID / 订单号主键分批依据主键、有无外键、触发器、关联业务视图 / 定时任务。业务口径确认「1 年前数据」时间边界核对 3000 万条数据量级避免误删有效数据。流量评估区分业务低峰期凌晨 00:00–06:00 优先执行记录日常 QPS、CPU、磁盘 IO 阈值。2. 备份底线方式 1优先物理备份xtrabackup整表 / 整库备份速度快、不锁业务。方式 2逻辑备份历史数据单独导出 1 年前数据备份后再删除满足合规溯源。禁止删除完成后再备份。3. 环境隔离与权限线上主库禁止手动直连大批量操作通过后台脚本 / 定时任务执行读写分离架构优先在从库做数据校验、预演再到主库执行。二、核心方案分批限流删除主流最优方案零业务影响方案思路利用主键 时间范围分页小批量删除每次只删少量行控制事务大小、行锁范围、IO 压力循环执行全程不阻塞线上读写。为什么不用DELETE FROM 表 WHERE 时间xxx 大批量 DELETE 会长事务、大量 undo 日志、行锁范围大、主从延迟飙升、IO 打满、线上查询超时。1. 关键参数设计通用参考单批次删除行数每次 100~500 行根据数据库性能微调高配库最大不超 1000批次间隔50~200ms限流削峰 IO、主从延迟执行窗口仅凌晨低峰运行白天停止规避业务流量。2. 具体 SQL 逻辑基于自增主键 id 时间1基础分页删除推荐最稳定-- 循环执行直到无满足条件数据 DELETE FROM order_table WHERE create_time 2025-06-07 00:00:00 AND id ? LIMIT 500; -- 单批行数执行逻辑记录上一轮最大id避免重复扫描全表每次只删 500 条短事务、锁范围极小每执行一轮sleep 100ms限流。2纯时间分页无自增主键用订单号 / 索引DELETE FROM order_table WHERE create_time 2025-06-07 00:00:00 ORDER BY create_time ASC LIMIT 500;3. 执行载体三种选择按架构选方式 1Shell 脚本 MySQL 客户端运维常用简单无侵入配合while循环 休眠低峰定时执行示例逻辑# 伪逻辑循环删除每次500条间隔100ms while true; do affected$(mysql -e DELETE FROM order_table WHERE create_time 2025-06-07 LIMIT 500; | wc -l) if [ $affected -eq 0 ]; then break; fi sleep 0.1 # 限流 done方式 2Java/Python 后台程序业务侧可控可加熔断增加开关、暂停 / 终止接口突发业务上涨可立刻停删监控数据库指标CPU/IO/ 主从延迟超标自动休眠记录执行日志、已删除条数便于对账。方式 3数据库定时事件不推荐仅纯运维库使用线上业务库禁用异常难以紧急终止。三、进阶优化高并发 / 大集群必备1. 主从架构专项处理主库分批删除从库会同步 binlog必然产生主从延迟监控从库延迟延迟 3s 自动加大sleep间隔或临时暂停严禁在延迟过高时继续执行。2. 大表优化先归档再删除超千万级终极方案如果该订单表日常查询极频繁单纯分批删除仍有 IO 压力采用归档分离新建归档表order_history_archive结构和原表一致分批迁移历史数据INSERT ... SELECT LIMIT到归档表迁移完成后再分批删除原表数据归档表可冷备份、下线、迁移至低成本存储OSS / 冷数据库。优势原表频繁访问的热数据完全不受影响IO 压力拆分。3. 禁止行为红线不执行DELETE 不带 LIMIT全量删除不执行TRUNCATE清空全表锁表、丢数据、无法回滚不在业务高峰、大促、报表时段执行不关闭 binlog主从集群会数据不一致不一次性加大批次量1000 行风险陡增。四、分阶段执行节奏3000 万条参考耗时以每批 500 行、间隔 100ms计算总批次60000 轮纯执行 休眠耗时约 1.67 小时结合人为停顿、指标监控分 2~3 个凌晨窗口跑完不单日一次性跑完留缓冲。第一晚试运行删 100 万条观察 CPU、IO、主从延迟、线上接口响应第二晚批量执行大部分数据第三晚收尾清理剩余数据。五、监控 应急兜底1. 实时监控指标数据库CPU、内存、磁盘 IO、连接数、慢查询、主从延迟 业务接口响应时间、报错率、QPS。2. 应急方案线上业务异常立刻停止删除脚本 / 程序无需回滚分批删除可断点续跑误删数据依赖前置备份恢复出现死锁 / 锁等待调小单批行数、加大休眠间隔。六、删除后收尾工作表空间回收InnoDB 大批量删除后会产生碎片数据文件不自动缩小。低峰执行ALTER TABLE order_table FORCE;或 轻量重建表根据碎片率选择碎片率高建议分批做完删除后择机做表重建优化查询性能。统计核对比对删除前后数据量确认 3000 万历史数据清理完成归档数据处置归档表定期冷备按需下线。七、长期方案避免再次出现大表表分区按时间分区月 / 年分区后续清理历史数据直接DROP PARTITION毫秒级完成无 IO 压力冷热数据分离热订单存主库N 个月前数据自动归档至历史库定时清理配置月度小批量清理任务避免数据堆积到千万级。总结最简落地版快速复述先全量备份核对时间条件与索引凌晨低峰执行主键 LIMIT 小批量删除500 行 / 批批次间休眠限流全程监控数据库与业务指标异常立即暂停清理完成后整理表碎片长期改用时间分区表根治大表清理问题。
