不推荐John推荐的这种技术，因为没有日志文件就不能保证数据库会附加。将数据库从full更改为simple，强制设置检查点并等待几分钟。SQL Server将清除日志，然后使用DBCC SHRINKFILE收缩日志。

这是一种简单且不优雅且有潜在危险的方法。

备份数据库 分离数据库 重命名日志文件 附加数据库 将重新创建新的日志文件 删除重命名日志文件。

我猜您没有做日志备份。(截断日志)。我的建议是将恢复模式从完全恢复改为简单恢复。这将防止日志膨胀。

略微更新的答案，针对MSSQL 2017，并使用SQL服务器管理工作室。 我基本上是从这些指示https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

我有一个最近的数据库备份，所以我备份了事务日志。然后我又备份了一次。 最后，我缩小了日志文件，从20G减小到7MB，这更符合我的数据大小。 自从2年前安装这个系统以来，我认为交易日志从来没有备份过。所以把这项任务写在家务管理日历上。

它发生在我身上，数据库日志文件是28 gb。

你能做些什么来减少这种情况呢? 实际上，日志文件是SQL服务器在事务发生时保存的文件数据。对于要处理的事务，SQL服务器为其分配页面。但在交易完成后，它们不会突然被释放，希望可能会有类似的交易到来。这撑起了空间。

步骤1: 首先在已探索的数据库查询中运行此命令 检查点

步骤2: 右键单击数据库 任务>备份 选择备份类型为事务日志 添加目标地址和文件名以保存备份数据(.bak)

再次重复此步骤，此时给出另一个文件名

步骤3: 现在转到数据库 右键单击数据库

>收缩>文件 “文件类型”选择“日志” 收缩动作释放未使用空间

步骤4:

检查日志文件 通常在SQL 2014中可以在

C:\Program Files\Microsoft SQL Server\MSSQL12。MSSQL2014EXPRESS \该\数据

在我的例子中，它从28 GB减少到1 MB

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

从DBCC SHRINKFILE (Transact-SQL)

您可能需要先备份。

到目前为止，这里的大多数回答都假设您实际上并不需要事务日志文件，但是，如果您的数据库使用FULL恢复模型，并且您希望保留备份以备需要恢复数据库时使用，那么不要像许多回答所建议的那样截断或删除日志文件。

删除日志文件(通过截断它、丢弃它、擦除它等)将破坏备份链，并将阻止您恢复到上一次完整、差异或事务日志备份以来的任何时间点，直到进行下一次完整或差异备份。

来自微软关于备份的文章

我们建议不要手动使用NO_LOG或TRUNCATE_ONLY 截断事务日志，因为这会中断日志链。直到 下一次全量或差异数据库备份时，数据库不备份 防止媒体故障。仅在very中使用手动日志截断 特殊情况，并立即创建数据备份。

要避免这种情况，请在收缩日志文件之前将其备份到磁盘。语法应该是这样的:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)