必须分批删除，单次delete超5000行易引发日志暴涨、锁表或9002错误；应使用delete top (n) + order by（字段需索引），并禁用外键约束、自动统计更新，监控主从延迟。
必须分批提交，单次 DELETE 超过 5000 行就极大概率触发日志暴涨、锁表或 9002 错误。 SQL Server 不会自动拆事务，你写一条 DELETE FROM t WHERE ...，它就真当一个事务跑到底——每行都记完整前像，日志文件不是“慢慢涨”，是“瞬间灌满”。
SQL Server 必须用 DELETE TOP (n) + ORDER BY 循环
不加 ORDER BY 的 TOP 是危险的：SQL Server 可能每次选不同行，导致漏删或重复删。也不要用 SET ROWCOUNT（已弃用）或子查询分页（性能崩、易跳过）。
-
TOP (5000)是实测安全上限，超过 10000 行单次事务日志压力陡增 -
ORDER BY字段必须是索引列（最好是主键），否则排序开销压垮 IO - WHERE 条件字段也必须有索引，否则每次循环都在全表扫描
- 示例结构：
WHILE 1=1<br>BEGIN<br> DELETE TOP (5000) FROM logs WHERE create_time IF @@ROWCOUNT = 0 BREAK;<br> WAITFOR DELAY '00:00:00.1';<br>END
别信“调大日志文件自动增长”就能扛住大删
把日志文件设成“无限制增长”只是拖延崩溃时间，不是解决方案。日志撑满的根本原因是活动事务没提交，CHECKPOINT 和 BACKUP LOG 都无法截断这部分空间。哪怕磁盘有 1TB 剩余，只要那个大事务还在跑，log_reuse_wait_desc 就一直显示 LOG_BACKUP 或 ACTIVE_TRANSACTION。
- 先查卡点：
SELECT name, log_reuse_wait_desc FROM sys.databases WHERE name = 'your_db' - 如果返回
ACTIVE_TRANSACTION，说明就是你那个没结束的 DELETE 在死扛 - 临时扩容日志只是给回滚留出空间，不是让大删合法化
容易被忽略的三个硬约束
再标准的分批逻辑，撞上这三条也会失败，而且报错往往不直接指向它们。
- 外键约束未禁用：
ALTER TABLE child NOCHECK CONSTRAINT fk_name必须提前执行，否则每批都校验外键，性能断崖下跌 - 自动统计更新开着：
ALTER DATABASE your_db SET AUTO_UPDATE_STATISTICS OFF，删一半时触发统计更新，锁表+扫全表 - 主从延迟高：如果在主库跑分批删，从库可能因单批执行太久而延迟飙升，甚至复制中断；需监控
replication lag并动态调小TOP值
真正难的不是写出循环语句，而是判断哪张表该用 3000 行一批，哪张得压到 1000 行——这取决于索引深度、行宽、日志备份频率和当前系统负载。跑之前，先在测试库用 DBCC SQLPERF(logspace) 看一眼日志使用率，删两批后立刻查，比任何理论都管用。
