1. 海量数据删除的挑战与解决思路
上周处理一个生产环境问题时，遇到一个包含3亿条记录的表需要清理历史数据。当我执行简单的DELETE语句后，数据库直接卡死，连带整个应用都出现了连接超时。这个惨痛教训让我意识到，在MySQL中处理海量数据删除需要完全不同的方法论。
与小型数据删除不同，海量数据操作会面临几个核心问题：
- 事务日志暴涨导致磁盘空间耗尽
- 长事务阻塞其他查询线程
- 锁竞争引发雪崩式性能下降
- 主从复制延迟急剧增加
经过多次实战验证，我总结出以下几种可靠的批量删除方案，每种方法都有其特定的适用场景和实现细节。下面通过具体案例来演示这些方法的实际应用。
2. 分批删除法（推荐方案）
2.1 基础实现原理
分批删除的核心思想是将一个大事务拆分为多个小事务，每个批次处理限定数量的记录。这种方法有效控制了单个事务的大小，避免产生巨型事务日志。
sql复制DELIMITER //
CREATE PROCEDURE batch_delete(IN batch_size INT, IN max_id INT)
BEGIN
DECLARE deleted_rows INT DEFAULT 1;
WHILE deleted_rows > 0 DO
START TRANSACTION;
DELETE FROM large_table
WHERE id <= max_id
LIMIT batch_size;
SET deleted_rows = ROW_COUNT();
COMMIT;
-- 控制删除速度
DO SLEEP(0.1);
END WHILE;
END //
DELIMITER ;
2.2 关键参数调优
-
批次大小选择：
- 常规服务器：建议500-2000行/批次
- 高性能SSD服务器：可提升至5000-10000行
- 测试公式：
batch_size = (innodb_buffer_pool_size * 0.5) / avg_row_size
-
休眠间隔：
- 主从架构：建议100-300毫秒
- 单机环境：可缩短至50毫秒
- 计算公式：
sleep_time = (batch_size / 1000) * replication_lag_factor
重要提示：务必在低峰期执行，并监控InnoDB历史列表长度（show engine innodb status中的History list length）
3. 表重建法（极速方案）
3.1 操作流程详解
当需要删除超过50%数据时，表重建往往比删除更高效。以下是具体步骤：
- 创建新表结构
sql复制CREATE TABLE new_table LIKE original_table;
- 迁移需要保留的数据
sql复制INSERT INTO new_table
SELECT * FROM original_table
WHERE create_time > '2023-01-01'; -- 保留条件
- 原子切换表（业务无感知）
sql复制RENAME TABLE original_table TO old_table,
new_table TO original_table;
- 后续清理（非阻塞操作）
sql复制DROP TABLE old_table; -- 低峰期执行
3.2 性能对比测试
在某次处理2.8亿条记录的案例中，不同方法耗时对比：
| 方法 | 耗时 | 锁等待时间 | 主从延迟 |
|---|---|---|---|
| 直接DELETE | 失败 | - | - |
| 分批删除 | 6.2h | 1.3s | 15min |
| 表重建法 | 1.5h | 0.05s | 2min |
4. 分区表方案（预防性设计）
4.1 分区表设计实践
对于需要定期清理的日志类数据，建议采用分区表设计。以下是按月分区的示例：
sql复制CREATE TABLE log_data (
id BIGINT AUTO_INCREMENT,
log_time DATETIME NOT NULL,
content TEXT,
PRIMARY KEY (id, log_time)
) PARTITION BY RANGE (TO_DAYS(log_time)) (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
4.2 分区维护操作
删除整个月份数据只需：
sql复制ALTER TABLE log_data DROP PARTITION p202301;
添加新分区：
sql复制ALTER TABLE log_data REORGANIZE PARTITION pmax INTO (
PARTITION p202303 VALUES LESS THAN (TO_DAYS('2023-04-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
5. 特殊场景处理方案
5.1 外键约束处理
当存在外键约束时，推荐流程：
- 禁用外键检查
sql复制SET FOREIGN_KEY_CHECKS = 0;
- 使用批处理删除
sql复制CALL batch_delete(1000, 1000000);
- 重建约束关系
sql复制SET FOREIGN_KEY_CHECKS = 1;
ALTER TABLE child_table ADD CONSTRAINT
FOREIGN KEY (parent_id) REFERENCES parent_table(id)
ON DELETE CASCADE; -- 建议级联删除
5.2 在线DDL工具应用
对于MySQL 5.6+版本，可以使用pt-online-schema-change工具：
bash复制pt-online-schema-change \
--alter "DELETE WHERE id < 1000000" \
D=database,t=large_table \
--chunk-size=1000 \
--sleep=0.1 \
--execute
工具优势：
- 自动分批执行
- 最小化锁等待
- 实时进度监控
- 出错自动回滚
6. 监控与优化要点
6.1 关键指标监控
执行过程中需要重点监控：
sql复制-- 查看长事务
SELECT * FROM information_schema.innodb_trx
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
-- 检查锁等待
SELECT * FROM sys.innodb_lock_waits;
-- 监控复制延迟
SHOW SLAVE STATUS\G
6.2 性能优化技巧
-
临时调整参数：
sql复制SET SESSION innodb_flush_log_at_trx_commit = 2; -- 提高写入性能 SET SESSION unique_checks = 0; -- 禁用唯一检查 -
索引优化：
- 删除前确保WHERE条件有合适索引
- 考虑使用FORCE INDEX提示
-
存储引擎切换：
sql复制ALTER TABLE large_table ENGINE=MyISAM; -- 删除前切换 -- 执行删除操作 ALTER TABLE large_table ENGINE=InnoDB; -- 完成后切换回
7. 实战经验总结
在最近一次金融系统升级中，我们使用分区表方案处理了4.2亿条交易记录。关键经验：
- 凌晨2点开始执行，业务低峰期
- 提前3天与DBA团队协调备份策略
- 使用pt-archiver工具做预删除测试
- 每删除500万条记录后手动执行CHECKPOINT
- 最终耗时2小时47分完成，期间业务无感知
特别提醒：无论采用哪种方案，务必先备份数据。我曾见过一个UPDATE误操作导致需要从备份恢复3TB数据，那个恢复过程持续了19个小时。