这种事务日志暴涨的情况我在处理数据库批量清理时遇到过不少，结合你的Python脚本调用存储过程的场景，给你几个针对性的解决方案：

1. 把大删除拆成小批量操作 #

你的Purge_Table存储过程里应该是一次性删除整张表的符合条件数据吧？这种单事务大删除会让日志文件疯狂膨胀。建议改成分批删除，每次只删固定数量的记录，循环直到清理完成：

WHILE EXISTS (SELECT 1 FROM TargetTable WHERE PurgeCondition)
BEGIN
    DELETE TOP(1000) FROM TargetTable WHERE PurgeCondition
    -- 可选：加个短延迟，给日志截断留一点时间
    WAITFOR DELAY '00:00:01'
END

每个小事务产生的日志量可控，不会一次性占满日志空间。

2. 临时调整数据库恢复模式 #

如果你的数据库用的是FULL恢复模式，所有DELETE操作的日志会被完整保留，直到你做日志备份才会截断。如果不需要点-in-time恢复功能，可以临时切换到SIMPLE模式：

ALTER DATABASE YourDatabaseName SET RECOVERY SIMPLE;

执行完清理后记得切回原模式，并且做一次完整备份（避免恢复模式切换后的数据保护缺口）：

ALTER DATABASE YourDatabaseName SET RECOVERY FULL;
BACKUP DATABASE YourDatabaseName TO DISK = 'D:\Backups\YourDB_Full.bak';

SIMPLE模式下，日志会在检查点运行后自动截断，不会持续积累。

3. 拆分存储过程的事务范围 #

检查一下Purge_DB是不是把所有表的清理操作都包裹在一个大事务里了？比如：

BEGIN TRANSACTION
EXEC Purge_Table TableA
EXEC Purge_Table TableB
EXEC Purge_Table TableC
COMMIT TRANSACTION

这种情况下，所有删除操作的日志都会被保留到整个事务提交，日志体积自然指数级增长。可以改成每个表清理完成后单独提交，或者每2-3个表提交一次，缩小单个事务的日志规模。

4. 预配置日志文件大小与增长规则 #

有时候日志暴涨是因为文件自动增长太频繁（比如每次只增长10%），导致大量碎片同时拖慢操作。可以手动把日志文件预增长到合适的大小：

ALTER DATABASE YourDatabaseName MODIFY FILE (NAME = YourDatabaseName_Log, SIZE = 8GB); -- 根据预估清理量设置

同时把自动增长改成固定大小（比如每次增长1GB），避免百分比增长带来的指数级膨胀：

ALTER DATABASE YourDatabaseName MODIFY FILE (NAME = YourDatabaseName_Log, FILEGROWTH = 1GB);

5. 清理后按需收缩日志（谨慎操作） #

如果清理完成后日志文件还是过大，可以手动收缩，但注意频繁收缩会产生文件碎片，不建议作为常规操作：

-- FULL恢复模式下先备份日志
BACKUP LOG YourDatabaseName TO DISK = 'NUL:';
-- 收缩日志到指定大小（比如100MB）
DBCC SHRINKFILE (YourDatabaseName_Log, 100);

内容的提问来源于stack exchange，提问作者garima arora