直接删除千万级数据会引发锁表、日志暴涨等问题；必须用id+时间双重约束分批删除，确保不漏不重；保留数据重建表更快但需停服；还需索引、恢复模式和执行时段三大前提保障。
直接用 DELETE FROM table WHERE date 删千万级数据，基本等于给线上服务下“停机令”：锁表、日志暴涨、查询卡死、tempdb 爆满——这不是删数据，是制造事故。
为什么不能只靠时间字段 + TOP 分批？
时间字段重复太常见（比如批量导入、毫秒精度缺失、业务逻辑允许同秒多条），导致 DELETE TOP (10000) FROM t WHERE create_time 每次都可能删同一组行，或跳过某些行。实测中漏删 5%～15% 是常态。
- 必须把删除范围锚定在唯一、有序、索引覆盖的列上，首选自增
id或identity列 - 即使
id是主键，ORDER BY id也必须显式写出，SQL Server 不保证TOP的隐式顺序 - WHERE 条件里要同时包含时间过滤和
id > @last_id，形成双重约束
安全分批 DELETE 的最小可靠模板
以下写法经生产环境验证，适用于 SQL Server 2005+，重点在「不漏、不重、可控、可中断」：
DECLARE @batch_size INT = 10000; DECLARE @rows_affected INT = 1; DECLARE @last_id BIGINT = 0; <p>WHILE @rows_affected > 0 BEGIN BEGIN TRANSACTION;</p><p>DELETE TOP (@batch_size) FROM orders WHERE order_date @last_id ORDER BY id;</p><p>SET @rows_affected = @@ROWCOUNT; SET @last_id = (SELECT ISNULL(MAX(id), @last_id) FROM orders WHERE order_date @last_id);</p><p>COMMIT TRANSACTION;</p><p>WAITFOR DELAY '00:00:00.05'; -- 防止日志写入过于密集 END</p>
-
@last_id必须每次更新，否则下一批会重复删或跳过 -
ORDER BY id不可省略，否则 SQL Server 可能任意选行，破坏顺序性 - 如果
id不是聚集索引，确保它有独立索引，否则性能断崖下跌 -
WAITFOR DELAY值不是固定套路，根据日志文件增长速度调：日志涨得快就加长，反之可缩短甚至去掉
比循环 DELETE 更快的替代方案：保留数据重建表
当你要删的是大多数（比如删 80%、只留 20%），DELETE 循环再怎么优化也是“搬沙子”，不如“换新桶”：
- 先用
SELECT INTO或CREATE TABLE ... AS SELECT把要保留的数据导出到新表（带索引结构更好） - 用
sp_rename切换表名，原表改名备份 - 确认无误后
DROP TABLE原表 - 注意：外键、权限、触发器不会自动迁移，需脚本补全；操作期间表不可写，务必安排在维护窗口
这个方案实际耗时往往是循环 DELETE 的 1/5，但代价是短暂服务中断和元数据手工同步——是否采用，取决于你更怕“慢”，还是更怕“停”。
容易被忽略的三个硬性前提
再正确的脚本，缺了这三项，照样崩：
-
order_date字段必须有索引（最好是复合索引(order_date, id)），否则每次WHERE order_date 都是全表扫描 - 数据库恢复模式若为
FULL，必须在执行前做一次日志备份，并考虑临时切到SIMPLE模式（操作完记得切回） - 务必在非高峰时段执行；哪怕加了
WAITFOR，凌晨 2 点跑和上午 10 点跑，对业务影响天壤之别
