教你几步快速搞定MSSQL日志清理，别让日志占满空间太烦人

（来源：CSDN博客《SQL Server日志文件清理方法汇总》） 直接开始：

第一步,先检查日志到底多大，别盲目删，打开SQL Server Management Studio，右键点你的数据库，选“属性”->“文件”，看看日志文件那一行的“大小”和“可用空间”，有时候你以为它占了几十个G，其实大部分是空着的，根本不用清，大小”很大而“可用空间”很小，那才是真需要清理。

第二步,搞清楚数据库的恢复模式，还是在数据库属性里，点“选项”看“恢复模式”。（来源：微软官方文档《SQL Server恢复模式》）这特别重要，因为清理方法和它能承受的风险直接挂钩。

• 简单模式：这个最省心，日志文件只是为了保证当前操作不崩溃，事务一完成，空间就能被重复利用，这种模式下日志还爆满，通常是日志文件本身太大，或者有超长未提交的事务卡着。
• 完整模式或大容量日志模式：这两种模式下，日志会一直增长，因为它要记录所有细节，以备将来恢复数据到某个时间点，你必须定期做“日志备份”，备份操作才会把已经提交事务的日志空间标记为可复用，如果你从不做日志备份，那日志文件就会无限变大，直到撑爆磁盘。

第三步,根据恢复模式选择清理方法。

情况A：数据库是【简单恢复模式】 （来源：Troubleshooting SQL Server日志文件过大问题） 方法1：直接收缩日志文件，执行SQL命令： DBCC SHRINKFILE ('你的日志文件逻辑名', 目标大小MB) DBCC SHRINKFILE ('MyDB_Log', 100) 意思是把日志文件缩到100MB，这个“逻辑名”就在第一步的数据库属性“文件”那里看，别搞错了，但要注意，不能缩得比当前正在使用的空间还小，否则会失败。

方法2：如果收缩不了，可能是还有活动事务，可以先做个检查点，把内存里的数据刷到硬盘，让日志更“干净”点：CHECKPOINT，然后再执行上面的收缩命令。

情况B：数据库是【完整/大容量日志恢复模式】 （来源：SQL Shack网站《How to shrink the SQL Server log》） 这是最常见也最让人头疼的情况，核心思路就一个：先做日志备份，再收缩。

1. 备份日志：在数据库上右键 -> “任务” -> “备份”，备份类型选“事务日志”，这会备份自上次日志备份以来的所有日志记录，并把备份完的那部分日志空间标记为可复用。
2. 检查空间是否释放：备份完后，再回第一步看看日志文件的“可用空间”是不是变大了，如果变大了，就可以进行下一步。
3. 收缩日志文件：和方法A里的命令一样，DBCC SHRINKFILE ('你的日志文件逻辑名', 目标大小MB)。

这里有个大坑：（来源：多位DBA的经验总结）你可能会发现，有时候刚备份完日志，可用空间是多了，但收缩文件只能缩一点点，或者干脆没效果，这往往是因为虽然逻辑上空间可复用了，但SQL Server为了性能，物理文件依然占着那些地方，可以尝试把目标大小设小一点，多执行几次收缩命令，但更根本的解决办法是……

第四步,预防永远比治疗重要，设置定期维护计划。

• 对于生产环境的重要数据库（用完整恢复模式）：你必须建立一个定期的作业。（来源：数据库运维最佳实践）每天深夜做一次完整备份，每隔几小时做一次日志备份，这样日志文件就不会累积得太大，千万别想着等快满了再去手动清理，那太危险了。
• 对于测试或开发环境（数据不重要）：如果不在乎数据丢失，可以直接把恢复模式改成“简单模式”，这样SQL Server会自动管理日志空间，你基本就不用管了，改的方法：数据库右键“属性”->“选项”->“恢复模式”选“简单”。

第五步,处理极端情况：日志文件巨大且无法收缩。 有时候数据库长期没人管，日志文件已经几百个G了，甚至把磁盘都塞满了，连备份操作都因为没空间而失败。 （来源：Stack Overflow高赞回答）

1. 紧急情况下,可以尝试把恢复模式临时改成“简单模式”，这会立即中断日志链，但能打破僵局，执行：ALTER DATABASE [你的数据库名] SET RECOVERY SIMPLE。
2. 改成简单模式后,立刻对日志文件进行一次收缩：DBCC SHRINKFILE ('你的日志文件逻辑名', 100)，这次通常能成功缩到很小。
3. 重要：收缩完后，记得根据你的需求，把恢复模式再改回“完整模式”：ALTER DATABASE [你的数据库名] SET RECOVERY FULL，然后立即做一次完整备份，因为改回完整模式后，新的日志链就从这次完整备份开始了。

最后提醒几个关键点：

• 别在业务高峰期做日志备份和收缩，这些操作会占用I/O资源，可能影响数据库性能。
• 收缩文件不是越频繁越好，反复放大缩小文件会导致文件碎片，影响性能，我们的目标是让日志文件维持在一个稳定、合理的大小。
• 如果以上方法都试了还是不行,就去查一下是不是有特别长的活动事务一直没结束（可以用DBCC OPENTRAN命令查看），或者有复制、镜像等高级功能在占用日志。

清理MSSQL日志的核心就是“对症下药”，先看恢复模式，再决定是直接收缩还是先备份再收缩，最重要的是养成定期备份的习惯，让日志增长处于可控状态，这样就不会被它搞得措手不及了。