1. 问题背景与核心挑战
作为一名长期与MySQL打交道的DBA，处理海量数据删除任务是绕不开的日常。记得去年清理某电商平台3年前的订单日志时，单表8亿条数据需要清理，直接执行DELETE FROM order_logs WHERE create_time < '2020-01-01'的后果就是——整个数据库集群被拖垮，业务投诉电话瞬间打爆。这种惨痛教训让我深刻认识到：批量删除不是简单的SQL执行，而是需要精密设计的手术式操作。
海量删除的三大致命影响：
- 锁表风暴：MyISAM引擎会直接锁全表，InnoDB虽然支持行锁，但大事务可能导致锁升级
- 日志膨胀：一个删除10亿条数据的操作，产生的undo日志可能比原表还大
- 性能雪崩：长时间占用IO和CPU资源，导致正常查询响应时间从毫秒级飙升到秒级
关键认知：删除操作的耗时与数据量不是线性关系，当超过某个临界点（通常百万级别）时，边际成本会指数级上升
2. 分批删除的工程化实践
2.1 LIMIT分块删除的进阶技巧
基础版的LIMIT分块删除大家都会，但实际生产环境需要考虑更多细节。这是我优化后的存储过程模板：
sql复制DELIMITER $$
CREATE PROCEDURE batch_delete(
IN p_table VARCHAR(64),
IN p_condition VARCHAR(1000),
IN p_batch_size INT,
IN p_sleep_seconds INT
)
BEGIN
DECLARE v_sql VARCHAR(2000);
DECLARE v_affected INT DEFAULT 1;
DECLARE v_total INT DEFAULT 0;
SET v_sql = CONCAT('DELETE FROM ', p_table,
' WHERE ', p_condition,
' LIMIT ', p_batch_size);
WHILE v_affected > 0 DO
SET @stmt = v_sql;
PREPARE stmt FROM @stmt;
EXECUTE stmt;
SET v_affected = ROW_COUNT();
SET v_total = v_total + v_affected;
-- 动态提交避免长事务
COMMIT;
-- 性能调节阀
IF p_sleep_seconds > 0 THEN
DO SLEEP(p_sleep_seconds);
END IF;
END WHILE;
SELECT CONCAT('Deleted ', v_total, ' rows') AS result;
END$$
DELIMITER ;
参数设计原理：
p_sleep_seconds：每批删除后的休眠时间，给数据库喘息机会- 动态SQL构建：支持任意表和条件
- 实时提交：避免产生一个持续数小时的事务
实测数据（AWS RDS MySQL 8.0，表大小500GB）：
| 批次大小 | 无休眠 | 休眠0.1秒 | 休眠0.5秒 |
|---|---|---|---|
| 1000 | 3.2h | 4.1h | 8.7h |
| 5000 | 1.9h | 2.5h | 5.3h |
| 10000 | 1.5h | 2.1h | 4.2h |
2.2 主键范围删除的优化方案
当表有自增主键时，范围删除确实比LIMIT更高效，但要注意几个坑：
sql复制-- 优化版的主键范围删除存储过程
DELIMITER $$
CREATE PROCEDURE range_delete(
IN p_table VARCHAR(64),
IN p_condition VARCHAR(1000),
IN p_batch_size INT
)
BEGIN
DECLARE v_min_id BIGINT;
DECLARE v_max_id BIGINT;
DECLARE v_current BIGINT;
-- 获取ID范围（强制使用索引）
SET @sql = CONCAT('SELECT MIN(id), MAX(id) INTO @v_min, @v_max FROM ',
p_table, ' WHERE ', p_condition);
PREPARE stmt FROM @sql;
EXECUTE stmt;
SET v_current = @v_min;
WHILE v_current <= @v_max DO
SET @batch_end = v_current + p_batch_size;
SET @delete_sql = CONCAT('DELETE FROM ', p_table,
' WHERE id BETWEEN ', v_current, ' AND ', @batch_end,
' AND ', p_condition);
PREPARE stmt FROM @delete_sql;
EXECUTE stmt;
-- 自适应步长调整
IF ROW_COUNT() < p_batch_size * 0.3 THEN
SET p_batch_size = p_batch_size * 2;
ELSEIF ROW_COUNT() > p_batch_size * 0.8 THEN
SET p_batch_size = p_batch_size / 2;
END IF;
SET v_current = @batch_end + 1;
COMMIT;
END WHILE;
END$$
DELIMITER ;
创新点：
- 动态调整批次大小：根据实际删除量自动扩大/缩小范围
- 双重条件保障：即使ID不连续也能确保数据准确性
- 索引提示：强制使用主键索引避免全表扫描
3. 高阶删除策略
3.1 分区表置换方案
对于超大型表（TB级别），我推荐使用分区表+分区置换的方案。这是我们在银行系统处理每日5亿级交易记录的方案：
sql复制-- 创建按月的分区表
CREATE TABLE transaction_logs (
id BIGINT AUTO_INCREMENT,
trans_date DATETIME,
-- 其他字段
PRIMARY KEY (id, trans_date)
) PARTITION BY RANGE (TO_DAYS(trans_date)) (
PARTITION p202201 VALUES LESS THAN (TO_DAYS('2022-02-01')),
PARTITION p202202 VALUES LESS THAN (TO_DAYS('2022-03-01')),
-- 其他月份分区
PARTITION pmax VALUES LESS THAN MAXVALUE
);
-- 删除整个过期分区（原子操作）
ALTER TABLE transaction_logs DROP PARTITION p202201;
性能对比：
| 方法 | 10GB数据删除耗时 | 锁持续时间 |
|---|---|---|
| 传统DELETE | 45分钟 | 持续 |
| 分区DROP | 0.3秒 | 瞬间 |
| 临时表替换 | 12分钟 | 表锁期间 |
3.2 在线DDL方案
MySQL 8.0+的原子DDL特性让表重建变得更安全：
sql复制-- 创建新表（包含需要保留的数据）
CREATE TABLE new_table AS
SELECT * FROM old_table WHERE create_time > '2023-01-01';
-- 原子替换（8.0+）
RENAME TABLE old_table TO old_backup, new_table TO old_table;
-- 异步清理
DROP TABLE old_backup;
注意事项：
- 确保磁盘空间足够（需要额外100%表空间）
- 在业务低峰期执行
- 提前创建好所有索引
4. 生产环境调优秘籍
4.1 参数调优组合拳
在批量删除前调整这些参数（操作后记得恢复）：
sql复制SET SESSION innodb_flush_log_at_trx_commit = 2; -- 降低日志刷盘频率
SET SESSION innodb_doublewrite = 0; -- 关闭双写缓冲
SET SESSION tx_isolation = 'READ-COMMITTED'; -- 使用读已提交隔离级别
效果对比：
| 参数组合 | 删除速度提升 | 风险等级 |
|---|---|---|
| 默认参数 | 基准 | ★★ |
| 仅调整flush_log | 35% | ★★★ |
| 全套优化 | 210% | ★★★★ |
4.2 监控指标看板
执行删除时需要实时监控这些指标：
Innodb_rows_deleted：已删除行数Innodb_buffer_pool_wait_free：缓冲池等待次数Threads_running：并发线程数Seconds_behind_master：主从延迟
推荐使用这个监控脚本：
bash复制watch -n 1 "mysqladmin ext -i1 | awk '/Queries|Innodb_rows_deleted|Threads_running|Bytes_received|Bytes_sent/'"
5. 血泪教训总结
千万不能踩的坑：
- 在复制环境下使用
LIMIT删除可能导致主从不一致 - 大事务回滚可能比执行删除耗时更长
- 没有备份直接操作（曾经误删7000万用户数据，靠binlog救了回来）
我的黄金法则：
- 先
SELECT COUNT(*)验证条件范围 - 在测试环境用
EXPLAIN确认执行计划 - 使用
--dry-run参数先模拟执行 - 准备好
STOP SLAVE;命令随时终止
最后分享一个真实案例：某次清理用户历史消息表，原本预估3小时完成，因为没注意到该表上有12个外键约束，最终执行了28小时。所以现在我的检查清单里永远多了一项——SHOW CREATE TABLE确认表结构。