我更倾向于使用备份日志+收缩数据库的方法，因为它是最安全可靠的方式，不会丢失数据，而且能彻底清理日志文件。步骤：先执行备份日志语句 BACKUP LOG [数据库名] TO DISK = 'NUL'，然后执行 DBCC SHRINKFILE 来收缩日志文件。

方法一：使用DBCC SHRINKFILE

DBCC SHRINKFILE('逻辑文件名', 目标大小) 这个命令可以直接缩小日志文件，但如果事务日志没有被备份，它不会生效，必须先备份日志。执行后日志会变小，但容易反复膨胀。

方法二：切换到简单恢复模式

ALTER DATABASE [数据库名] SET RECOVERY SIMPLE; 然后 DBCC SHRINKFILE 收缩，再切回 FULL 模式 ALTER DATABASE [数据库名] SET RECOVERY FULL; 这种方法简单，但会丢失日志备份点，适合测试环境，不推荐生产。

方法三：备份日志到NUL

BACKUP LOG [数据库名] TO DISK = 'NUL' 这会清空日志而不保存备份文件，然后收缩。非常实用，日志瞬间变小，不会影响恢复模式。

方法四：使用第三方工具

像SQL Server Management Studio的右键任务-收缩文件，或者用ApexSQL Log等工具，但这些不彻底，日志还会增长。

对比总结

简单模式快但不安全；备份到NUL+收缩平衡；SHRINKFILE单独用无效；我倾向备份日志+收缩，因为生产环境需要完整日志链。

实际案例

一次日志占满100G磁盘，用BACKUP LOG testdb TO DISK='NUL'后SHRINKFILE，日志从100G缩到1G，完美解决。

FAQ
Q: 为什么日志文件会无限增长？
A: 因为FULL恢复模式下未备份日志，事务不断积累。
Q: 收缩后还会变大吗？
A: 会，如果不定期备份日志，必须养成习惯。
Q: 生产环境能用简单模式吗？
A: 不推荐，丢失点-in-time恢复能力。
Q: 怎么查日志文件逻辑名？
A: SELECT name FROM sys.master_files WHERE database_id = DB_ID('数据库名') AND type_desc = 'LOG';