1. 前言
MSSQL作为一款流行的关系型数据库管理系统，具有高效、稳定等特点，第一次安装完后，一般都会设置初始大小，在此基础上，不断地添加数据和建立新表，这也就会涉及到LOG文件，我们可以将之简单理解为一个记录文件，用于记录数据库个表的所有修改，包括增删改操作。
随着数据量的增多，LOG文件也会越来越大，萎缩或备份日志等操作可以一定程度上减小文件大小，但难以达到清空文件的目的，因此，如何清理数据库LOG空间成为每个数据库管理员必须要面对的问题。
2. MSSQL数据库清理LOG空间的操作方法
2.1 检查数据库使用的Recovery Model
在进行数据库清理操作之前，首先需要检查所使用的Recovery Model，可使用以下脚本查看：
use [database_name]
select name,recovery_model_desc from sys.databases
在运行脚本后，将会返回当前所有数据库的信息，其中recovery_model_desc列就是所使用的恢复模式，根据该模式选择适当的清理策略。
注：在Simple Recovery Model模式下，只有被清理了的部分才能被释放掉，而在Full Recovery Model和Bulk-Logged Recovery Model模式下，整个日志文件都需要被清理，因此需要进行备份操作。
2.2 检查当前数据库日志文件所占用空间
执行以下脚本可以查看当前数据库日志文件所占用的空间大小：
USE [database_name]
GO
DBCC SQLPERF (LOGSPACE)
GO
在脚本运行后，系统会返回当前数据库LOG文件的大小和使用率等信息。
根据过长的日志，我们可使用如下脚本清除它：
use [database_name]
go
checkpoint
go
DBCC SHRINKFILE([log_file_name])
注：log_file_name 为日志文件名，注意将其替换为实际使用的日志文件名。2.3 间隔性地备份日志文件
备份日志文件可以将日志文件区域清空，从而释放空间。以下是备份日志文件的脚本代码：
-- 请先看一下旧的备份的剩余信息
DBCC SQLPERF(LOGSPACE)
-- 备份日志，日志备份策略根据alexazhu DBA规范定制(重要策略)
BACKUP LOG [数据库名] TO DISK = 'd:\分布式系统实验室\DBBackup\fu10_newdb\FULL\FU10_NewDB_LOG_%DATETIME%.trn' with NO_TRUNCATE, INIT, NOFORMAT;
-- 查看新的日志，可能比刚才还大，原因效应类似truncatelog导致
DBCC SQLPERF(LOGSPACE)
-- 如果当前的日志空间使用率很低，调用DBCC SHRINKFILE()处理日志文件
-- 注意：这个强行收缩日志，是非常粗暴的办法，生产环境下，不建议使用，因为会影响数据库性能。
-- 如果可以，还是将日志文件大小设置到一个合理值后，控制日志文件增长
3. 优化应用系统，减少LOG文件过多现象出现
3.1 开启自动收缩
自动收缩环节在数据库实例运行时定期执行，可根据数据库活动量、频率、操作类型等，自动完成LOG文件的压缩，降低数据库体积，提升性能。在配置自动收缩功能时，建议设置多个时间段，如每小时运行一次，同时也可进行手动运行，用户可根据实际情况进行调节。
以下是开启自动收缩的脚本代码：
USE [database_name]
GO
ALTER DATABASE [database_name] SET AUTO_SHRINK ON WITH NO_WAIT
GO
3.2 控制事务提交
事务提交是数据库操作中的重要环节，每次执行SQL语句时，都会要求事务完成，这也会对LOG文件大小起到直接影响。因此，在实际应用中，应尽量避免过多地进行事务提交操作，合理控制事务的大小和提交次数。
以下是控制事务提交的脚本代码：
BEGIN TRANSACTION;
IF(@@TRANCOUNT>0)
COMMIT TRANSACTION;
GO
3.3 减少DDL操作
DDL操作（增删改表结构）会占用较多的LOG文件空间，在实际应用中，要尽可能地减少这类操作的次数。在必要情况下，也可尝试使用一些第三方工具进行处理。
4. 结语
MSSQL数据库清理LOG空间并不是一件很容易的事情，需要有一定的技术支持，但使用合理的方法和手段，可以极大地提升数据库性能，减少应用出现故障的可能性。因此，在日常的数据库管理工作中，数据库管理员需要注意上述方法的使用，并不断地进行优化，以达到更高效的运行效果。