大事务在SQL Server中会引发日志膨胀、锁阻塞、回滚卡死及磁盘打满等严重风险，因其持续占用日志空间、延长锁持有时间且回滚不可控；应通过拆分事务、监控活跃会话、保障日志备份链畅通来预防，收缩日志仅作紧急止血且须严格按序操作。
大事务在SQL Server中不是“慢一点”的问题，而是直接触发日志膨胀、锁阻塞、回滚卡死甚至磁盘打满的风险源。核心矛盾在于：事务越长，日志写得越多、锁占得越久、回滚越不可控。
为什么大事务会让日志暴涨
在完整恢复模式下，SQL Server必须保留所有已提交事务的日志，直到执行一次日志备份（BACKUP LOG）才能截断。而一个运行数小时的大事务（比如批量导入100万行），会持续占用日志空间——因为它的事务ID始终“活跃”，相关VLF（虚拟日志文件）无法被标记为可重用。
- 日志不是按“时间”清理，而是按“事务完成+备份”双条件截断
- 单个事务修改50万行，就会生成至少50万条日志记录（含前后像、索引更新、页分配等）
- 频繁小增量增长（如每次自动扩展1MB）会导致VLF数量爆炸，严重拖慢日志备份和数据库恢复速度
回滚为何又慢又危险
回滚不是“撤销按钮”，而是重放逆向操作：把每一条INSERT变DELETE、每一条UPDATE还原旧值、再逐个检查约束和触发器。这个过程全靠日志驱动，且全程持有排他锁。
- 正在回滚的事务仍锁住所有已修改的数据页，其他查询只能等待，表现为“整个库变卡”
- 回滚本身是单线程操作，无法并行；数据量翻倍，回滚时间远不止翻倍（涉及I/O、内存、锁竞争叠加）
- KILL掉一个回滚中的会话，不会立即结束——系统必须先完成当前日志段的回退步骤，可能比让它自然跑完还久
真正有效的应对方式
别等它出事再收缩日志或KILL进程。重点在预防和分治：
- 拆分事务：用批处理控制规模，例如每次UPDATE 5000行后显式COMMIT，避免单事务跨表、跨索引、带触发器的大范围操作
- 监控活跃事务：定期运行 DBCC OPENTRAN 或查 sys.dm_exec_requests 中 status = 'rollback' 或 wait_type LIKE 'LCK%' 的会话
- 确保日志备份链畅通：生产库必须配置定时日志备份（如每15分钟一次），这是释放日志空间的唯一合规路径
- 开发/测试库可设为简单恢复模式，但上线前务必切回完整模式，并立即做一次完整备份重建日志链
收缩日志不是解药，而是临时止血
如果日志已涨到50GB且磁盘告急，可以紧急收缩，但必须严格按顺序操作：
- 先执行日志备份（BACKUP LOG DBName TO DISK='x.bak'）
- 再运行 DBCC SHRINKFILE (逻辑名, 目标MB)，目标值建议不低于最近24小时日志生成量的1.5倍
- 禁止在生产环境反复执行SHRINK——它会造成日志文件碎片，下次增长更慢、VLF更多、性能更差
