不能直接用 delete from table_name 清空大表，因其逐行记日志、易致日志满、锁升级和阻塞；truncate 快但不支持条件删除；推荐用 delete top(n) 分批删，需加事务、where 和排序依据，并注意外键处理及删后索引维护。
为什么不能直接用 DELETE FROM table_name 清空大表
执行全表 DELETE 会逐行记录日志、占用大量事务日志空间，容易触发日志满、锁升级（如页锁→表锁）、阻塞其他查询，甚至导致超时或事务回滚失败。在几十GB以上的表上，它可能跑几个小时还卡住。
TRUNCATE TABLE 快但不支持带条件的分批删除
TRUNCATE TABLE 确实快——它只释放数据页、不记单行日志、不触发触发器、重置 IDENTITY 值。但它只能清空整张表，不能加 WHERE 条件，也不支持分批控制。如果你只想删旧数据（比如保留最近6个月），TRUNCATE 就完全不合适。
用 DELETE TOP (n) 循环分批删，必须加显式事务和 WHERE 条件
这是最常用也最可控的方式。核心是：每次只删固定行数，提交事务，避免日志暴涨和长事务锁定。
- 必须指定排序依据（通常是主键或时间字段），否则
TOP行为不可预测，可能重复删或漏删 - 每次循环后检查影响行数，为0则退出；建议用
@@ROWCOUNT判断 - 每批大小需权衡：太小（如100行）→ 循环开销大；太大（如10万）→ 单次日志压力高；通常 5000–10000 是较稳妥起点
- 示例（按
CreatedTime删除2024年前的数据）：
WHILE 1 = 1
BEGIN
DELETE TOP (5000)
FROM Orders
WHERE CreatedTime IF @@ROWCOUNT = 0 BREAK;
WAITFOR DELAY '00:00:00.01'; -- 避免 CPU 空转
END
注意：WAITFOR DELAY 不是必须，但在高并发场景下可缓解资源争抢。
外键约束存在时，先禁用再恢复会出问题
有人想用 ALTER TABLE ... NOCHECK CONSTRAINT 临时关外键来加速删除，这是危险操作。即使成功删完，后续开启约束时 SQL Server 会验证全部数据一致性，可能卡死或失败（尤其大表）。更稳妥的做法是：
- 确认子表是否也要删对应数据；如果要，先按依赖顺序删子表（如先删
OrderItems，再删Orders） - 若只是父表删数据且子表无关联记录，可忽略外键影响；但务必提前验证，不能靠“应该没数据”赌
- 绝不推荐用
NOCHECK+CHECK组合绕过验证——这等于埋下数据不一致隐患
真正麻烦的不是怎么删，而是删完后索引碎片飙升、统计信息过期——这些不会自动修复，得手动 UPDATE STATISTICS 或重建索引，否则后续查询性能可能断崖下跌。
