1. 海量数据删除的挑战与解决思路
在数据库运维中，我们经常会遇到需要清理历史数据的场景。当表数据量达到千万甚至上亿级别时，简单的DELETE语句可能会引发灾难性后果。我曾经处理过一个电商平台的订单表清理任务，单表8亿数据，直接执行DELETE导致数据库锁死长达6小时，最终只能kill进程回滚。
海量数据删除的核心痛点在于：
- 事务日志暴增：每条删除记录都会写入事务日志
- 锁资源占用：大事务可能导致锁等待甚至死锁
- 主从延迟：从库应用大量删除操作耗时剧增
- 磁盘IO压力：删除操作产生大量随机IO
针对这些问题，业内主要有以下几种解决方案：
2. 常规DELETE的优化方案
2.1 分批删除法
最基础的优化思路是将大事务拆分为小事务。以下是推荐的分批删除模板：
sql复制DELIMITER //
CREATE PROCEDURE batch_delete(IN batch_size INT, IN max_id INT)
BEGIN
DECLARE min_id INT DEFAULT 0;
WHILE min_id < max_id DO
DELETE FROM large_table
WHERE id BETWEEN min_id AND min_id + batch_size - 1;
SET min_id = min_id + batch_size;
COMMIT;
DO SLEEP(0.1); -- 控制删除频率
END WHILE;
END //
DELIMITER ;
关键参数说明：
- batch_size：建议500-5000之间，需要根据行大小调整
- sleep间隔：给数据库喘息时间，避免IO尖峰
注意：务必确保WHERE条件使用索引，否则会导致全表扫描
2.2 时间维度分批
对于按时间排序的数据，更推荐按时间区间删除：
sql复制DELETE FROM log_table
WHERE create_time < '2023-01-01'
LIMIT 10000;
配合Shell脚本循环执行，直到affected_rows为0。这种方式的优势是：
- 避免主键不连续导致漏删
- 更符合业务数据的自然分布特征
3. 表重建方案
3.1 创建新表替换
当需要删除超过50%数据时，考虑用新建表替换原表：
sql复制-- 1. 创建新表（只保留需要的数据）
CREATE TABLE new_table AS
SELECT * FROM old_table WHERE create_time > '2023-01-01';
-- 2. 重命名表（原子操作）
RENAME TABLE old_table TO old_table_backup, new_table TO old_table;
-- 3. 重建索引（可选）
ALTER TABLE old_table ADD INDEX idx_col1(col1);
优势：
- 执行速度快（特别是MyISAM引擎）
- 不会产生碎片
- 锁时间极短
注意事项：
- 确保磁盘空间足够（需要额外存储新表）
- 外键约束需要特殊处理
- 大表重建期间内存消耗较大
3.2 分区表方案
对于持续增长的海量数据表，建议设计为分区表：
sql复制-- 创建按月的RANGE分区
CREATE TABLE log_data (
id BIGINT,
log_time DATETIME,
content TEXT
) 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
);
-- 删除整个分区（瞬间完成）
ALTER TABLE log_data DROP PARTITION p202301;
分区删除的特点：
- 实际是删除文件，速度极快
- 不会产生undo日志
- 需要提前规划分区策略
4. 特殊场景解决方案
4.1 大表带索引删除
当表有多个二级索引时，删除操作会额外维护索引。优化方案：
- 先删除非必要索引
- 执行数据删除
- 重建索引
sql复制-- 删除索引
ALTER TABLE large_table DROP INDEX idx_1, DROP INDEX idx_2;
-- 执行批量删除
CALL batch_delete(1000, 10000000);
-- 重建索引（比边删边维护快5-10倍）
ALTER TABLE large_table ADD INDEX idx_1(col1), ADD INDEX idx_2(col2);
4.2 外键约束处理
有外键引用时，需要：
- 先删除子表数据
- 或临时禁用外键检查
sql复制SET FOREIGN_KEY_CHECKS = 0;
-- 执行删除操作
SET FOREIGN_KEY_CHECKS = 1;
警告：禁用外键检查可能导致数据不一致，需确保业务逻辑正确性
5. 性能对比与选型建议
通过基准测试对比不同方案（10GB表，删除50%数据）：
| 方案 | 耗时 | 锁时间 | 主从延迟 | 磁盘IO |
|---|---|---|---|---|
| 直接DELETE | 6小时 | 持续 | 严重 | 极高 |
| 分批DELETE(1000) | 2小时 | 间歇 | 中等 | 中 |
| 新建表替换 | 45分钟 | 秒级 | 轻微 | 高 |
| 分区表DROP | 1秒 | 秒级 | 无 | 低 |
选型建议：
- 删除量<30%：分批DELETE
- 删除量30-70%：新建表替换
- 删除量>70%：分区表DROP
- 持续增长数据：提前设计为分区表
6. 实战经验与避坑指南
-
监控要点：
- 关注
Innodb_rows_deleted状态变量 - 监控
long_queries和锁等待 - 从库延迟监控不能遗漏
- 关注
-
中断恢复技巧：
sql复制-- 记录上次删除的ID位置 SELECT @last_id := MAX(id) FROM delete_progress; -- 续传时从上次位置开始 DELETE FROM large_table WHERE id > @last_id LIMIT 1000; -
隐式陷阱：
- AUTO_INCREMENT值不会重置（需ALTER TABLE重置）
- 碎片问题（OPTIMIZE TABLE可能锁表，建议用pt-online-schema-change）
- 触发器执行次数可能超出预期
-
工具推荐：
- pt-archiver：专业的数据归档工具
- gh-ost：在线DDL工具辅助表重建
- mysqldump配合WHERE条件导出需要保留的数据
我曾经在一个金融系统中用分批删除法清理3亿条交易记录，最初设置的batch_size=5000，结果发现磁盘IOPS持续保持在90%以上。后来调整为batch_size=1000并增加sleep间隔，整个删除过程对业务的影响降到了可接受范围。这个案例告诉我，没有放之四海而皆准的参数，必须根据实际硬件配置和业务压力动态调整。