核心结论：针对 SQL Server 千万级数据的清理操作，切勿试图通过单条 DELETE 语句完成。必须采用分批提交策略，否则将引发事务日志暴涨、表锁定以及主从复制延迟——这三项连锁问题无一例外都会出现。
为什么单次 DELETE 会导致事务日志文件急剧膨胀
SQL Server 在执行每行删除时，都会在事务日志中记录完整的前映像（用于回滚）和事务元数据。删除 500 万行意味着产生 500 万条日志记录，且整个操作封装在一个大事务内，导致日志无法截断，直至事务提交。即便启用了 FULL 恢复模式并配置了日志备份，只要该大事务未结束，备份操作也无法释放已占用的日志空间。
- 典型症状：错误号
9002（日志空间不足）、LOG_BACKUP备份失败，以及DBCC SQLPERF(logspace)显示日志使用率持续处于 99% 的高位 - 问题根源并非磁盘容量不足，而是事务日志处于“活跃”状态无法释放
- 即便添加了
WHERE条件并有效利用索引，也无法规避单事务内日志累积的固有问题
使用 DELETE TOP (n) 循环删除时必须注意三个关键要素
仅编写简单的 DELETE TOP (5000) FROM t WHERE ... 语句是不够完善的方案，极易引发问题。
- 必须配合
ORDER BY子句（例如ORDER BY id），否则可能造成重复删除或遗漏删除，因为TOP关键字本身不保证稳定的行顺序 - 每次删除后加入
WAITFOR DELAY '00:00:00.1'（即 100 毫秒）的延迟，为检查点（Checkpoint）和日志截断操作提供执行窗口 - 使用
IF @@ROWCOUNT = 0 BREAK判断循环终止条件，避免采用EXISTS(SELECT 1 FROM ...)查询剩余记录，因为后者可能触发全表扫描或全索引扫描
临时调整恢复模式与统计信息设置以优化删除性能
在默认配置下，分批删除操作可能被拖慢，同时日志增长问题也更为隐蔽。
- 首先检查当前恢复模式：运行
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'YourDB'；若结果为FULL，则必须确保日志备份任务处于活动状态，否则分批删除也无法有效控制日志增长 - 临时禁用自动统计更新：执行
ALTER DATABASE YourDB SET AUTO_UPDATE_STATISTICS OFF，待删除完成后重新启用。否则每次批次删除都会触发统计更新，导致表扫描和日志写入的双重开销 - 避免在业务高峰期运行；若表上存在触发器，应先行禁用（使用
DISABLE TRIGGER），删除操作结束后再启用，以防止产生额外的日志记录和锁竞争
如何确定分批大小与实际效果的平衡点
分批大小并非越大越高效，亦非越小越稳定，需根据实际 I/O 和锁等待情况进行调整。
- 初始建议使用
TOP (5000)至TOP (10000)的范围。批次过小（如 100）会使事务开销占比过高，导致 CPU 和日志写入频次增加；批次过大（如 50000）则单次日志压力依然显著，锁持有时间也会延长 - 监控
sys.dm_exec_requests中的wait_type列：若频繁出现LCK_M_U或WRITELOG等待类型，表明锁或日志写入已成为瓶颈，需减小批次大小或延长WAITFOR延迟时间 - 关注
tempdb压力：若语句涉及排序操作（如ORDER BY使用非索引列），大量sort操作会占用tempdb空间，间接降低日志写入速度
在实际应用中，导致性能瓶颈的往往并非循环逻辑本身，而是忽略了禁用自动统计、忘记检查恢复模式，或将 WAITFOR 设置为秒级延迟却抱怨主从同步延迟——这些细节若未妥善处理，分批删除策略也难以奏效。
