在数据库日常运维和数据处理场景中,经常会遇到需要删除大量历史数据的情况,比如清理超过保留期限的业务日志、删除测试环境冗余数据等。如果直接使用DELETE语句一次性删除百万甚至千万级别的数据,很容易引发事务日志急剧增长、表锁持有时间过长、数据库CPU和IO负载飙升等问题,严重时甚至会导致数据库服务暂时不可用。使用脚本分段删除的方式,可以将大删除任务拆分成多个小批次执行,每次只处理少量数据,有效降低单次操作对数据库的压力,同时还能灵活控制删除节奏,避免影响线上业务的正常运行。

为什么不建议一次性删除大量SQL数据
直接使用DELETE语句删除大量数据存在多个明显的风险点,了解这些风险能帮助我们更清楚分段删除的必要性:
- 事务日志暴涨:DELETE操作会记录每一条删除的数据到事务日志中,删除的数据量越大,生成的日志越多,可能导致日志文件占满磁盘空间。
- 长锁表问题:大批量删除会长时间持有表的锁,期间其他对该表的读写操作都会被阻塞,影响业务正常访问。
- 回滚风险高:如果一次性删除过程中出现异常需要回滚,回滚操作本身也会消耗大量资源,甚至比删除操作本身更耗时。
- 资源占用过高:大量数据删除会持续占用数据库CPU、IO资源,可能导致同实例的其他数据库业务响应变慢。
分段删除的核心实现思路
分段删除的核心逻辑是将原本一次性的大删除任务,拆分成多次小批次的删除操作,每次只删除固定数量的数据,批次之间可以添加短暂的等待时间,让数据库有时间处理其他请求。常见的实现思路有两种:
基于主键ID分段删除
如果表有自增主键或者有序的主键ID,可以按照ID范围拆分删除批次,每次删除一个ID区间内的符合条件的数据。这种方式效率较高,因为ID通常有索引,范围查询速度快。
基于固定行数分段删除
如果没有合适的范围字段,可以使用TOP或者LIMIT关键字,每次只删除固定行数的符合条件的数据,循环执行直到所有符合条件的数据都被删除。这种方式适用性更广,不需要依赖特定的有序字段。
不同数据库的分段删除脚本示例
SQL Server分段删除脚本
SQL Server中可以使用TOP关键字配合WHILE循环实现分段删除,以下示例是删除表中创建时间超过30天的记录,每次删除1000条:
-- 定义每次删除的行数
DECLARE @BatchSize INT = 1000
-- 定义总删除行数变量
DECLARE @DeletedRows INT = 1
-- 循环执行删除,直到没有符合条件的数据
WHILE @DeletedRows > 0
BEGIN
-- 每次删除1000条符合条件的数据
DELETE TOP (@BatchSize)
FROM 业务表名
WHERE 创建时间字段 < DATEADD(DAY, -30, GETDATE())
-- 获取本次删除的行数
SET @DeletedRows = @@ROWCOUNT
-- 每批次删除后等待100毫秒,降低数据库压力
WAITFOR DELAY '00:00:00.100'
END
MySQL分段删除脚本
MySQL中可以使用LIMIT关键字配合循环实现分段删除,以下示例同样是删除创建时间超过30天的记录,每次删除1000条:
-- 定义每次删除的行数
SET @batch_size = 1000;
-- 循环删除,直到没有符合条件的数据
REPEAT
-- 每次删除1000条符合条件的数据
DELETE FROM 业务表名
WHERE 创建时间字段 < DATE_SUB(NOW(), INTERVAL 30 DAY)
LIMIT @batch_size;
-- 获取本次删除的行数,MySQL中ROW_COUNT()返回上一条语句影响的行数
SET @deleted_rows = ROW_COUNT();
-- 短暂等待,降低压力
DO SLEEP(0.1);
UNTIL @deleted_rows = 0 END REPEAT;
PostgreSQL分段删除脚本
PostgreSQL中可以使用LIMIT配合循环实现分段删除,示例如下:
-- 定义每次删除的行数
DO $$
DECLARE
batch_size INT := 1000;
deleted_rows INT := 1;
BEGIN
WHILE deleted_rows > 0 LOOP
-- 每次删除1000条符合条件的数据
DELETE FROM 业务表名
WHERE 创建时间字段 < CURRENT_DATE - INTERVAL '30 day'
LIMIT batch_size;
-- 获取本次删除的行数
GET DIAGNOSTICS deleted_rows = ROW_COUNT;
-- 短暂等待,降低压力
PERFORM pg_sleep(0.1);
END LOOP;
END $$;
分段删除的注意事项
在使用脚本分段删除数据时,还需要注意以下几点,避免操作出现问题:
- 提前备份数据:删除操作不可逆,执行前一定要确认符合条件的数据已经备份,或者先在测试环境验证删除条件是否正确。
- 添加合适的索引:删除条件中的字段最好有索引,否则每次小批次删除也会进行全表扫描,反而降低效率,增加数据库压力。
- 控制批次大小:批次大小需要根据数据库性能调整,一般建议单次删除行数在500到2000之间,太小会导致循环次数过多,太大会失去分段的意义。
- 避免业务高峰期执行:即使分段删除压力较小,也尽量避开业务访问高峰时段执行,选择凌晨等低峰时段操作更安全。
- 监控执行过程:执行过程中可以监控数据库的事务日志大小、锁等待情况、CPU和IO负载,如果出现异常可以及时终止操作。
分段删除与TRUNCATE的区别
很多开发者会混淆分段删除和TRUNCATE操作,两者的适用场景差异很大:
| 对比项 | 分段删除(DELETE分段) | TRUNCATE |
|---|---|---|
| 适用场景 | 删除部分符合条件的数据 | 清空整张表的所有数据 |
| 是否可加条件 | 可以加WHERE条件筛选数据 | 不能加条件,只能清空全表 |
| 事务日志 | 记录每一条删除的数据,日志量较大 | 只记录页分配相关的日志,日志量很小 |
| 锁级别 | 行级锁或者页级锁 | 表级锁 |
| 自增ID处理 | 不影响自增ID的当前值 | 会重置自增ID的当前值为初始值 |
| 可回滚性 | 在事务中可以回滚 | 大部分数据库中不能回滚 |
如果确实需要清空整张表且不需要保留自增ID当前值,TRUNCATE是效率更高的选择,但如果只是删除部分数据,分段删除是更安全合适的方案。