单次删除千万行会引发日志暴涨、表锁阻塞及回滚灾难；分批删除无需强制order by，但强烈建议添加以避免重复或漏删，且需确保条件字段有索引。
为什么不能直接用 DELETE FROM table WHERE ...
单次删除千万行会把整个操作塞进一个事务里，日志文件（.ldf）瞬间暴涨，可能占满磁盘；同时锁升级大概率变成表锁，阻塞所有读写。你看到的“执行中”状态，其实是其他业务在等你释放锁。更糟的是，如果中途失败或超时，回滚过程本身又是一场灾难——它要重放全部日志，耗时可能比删除还长。
DELETE TOP (n) 分批删除必须加 ORDER BY 吗？
不必须，但强烈建议加。SQL Server 的 TOP 在无 ORDER BY 时行为不确定：可能重复删同一行、漏删某些行，尤其在并发环境下。实际执行前先确认删除条件字段有索引（比如 createdate 或 status），再写成：
DELETE TOP (5000) FROM dbo.orders WHERE status = 'cancelled' AND createdate <p>这样能保证每次从最老的记录开始删，顺序可控，也利于后续归档或监控进度。</p> <h3>分批删除时要不要加 <code>WAITFOR DELAY</code>？</h3> <p>要看负载情况。如果你的数据库白天还在跑核心交易，那必须加——哪怕只停 <code>'00:00:00.1'</code>（100 毫秒），也能让出 I/O 和锁资源给其他会话。但如果是凌晨维护窗口且无其他负载，可以去掉，加快整体速度。注意：<code>WAITFOR DELAY</code> 不影响事务本身，只控制循环节奏，别把它和事务提交混淆。</p>
- 低峰期（如凌晨 2 点）：可设为
'00:00:00.05' - 生产高峰期旁路执行：建议
'00:00:00.2'起步，观察sys.dm_exec_requests中的等待类型（如WRITELOG或LCK_M_U）是否下降 - 别用
WAITFOR TIME，它不可控，容易卡住整段逻辑
简单恢复模式真能关日志增长吗？
能，但只在「你明确接受日志链断裂」的前提下才安全。切到简单模式后，检查点（CHECKPOINT）会自动截断日志，避免 .ldf 持续膨胀。但切换前后必须做两件事：
- 切换前：确保最近一次完整备份已完成（
BACKUP DATABASE） - 切换后执行完删除：立刻切回完整模式，并立即补一个日志备份（
BACKUP LOG），否则后续日志链无法续上
分区表方案虽快（SWITCH PARTITION + DROP 几乎瞬时），但它要求表**早已按时间/状态建好分区函数和方案**，临时加分区会锁表并重建，反而更慢。别指望靠它救急。
