对MDB文件进行备份。 停止SQL服务 重命名日志文件 启动服务

(系统将创建一个新的日志文件。)

删除或移动重命名的日志文件。

首先检查数据库恢复模型。默认情况下，SQL Server Express Edition会为简单恢复创建一个数据库 (如果我没记错的话)。

备份日志DatabaseName With Truncate_Only

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile将为您提供逻辑日志文件名。

请参考:

从SQL Server数据库中的完整事务日志中恢复

如果您的数据库处于完全恢复模式，并且您没有进行TL备份，那么将其更改为SIMPLE。

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

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

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

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

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

备份数据库 分离数据库 重命名日志文件 附加DB(同时附加删除重命名的.ldf(日志文件)。选择它并按下删除按钮) 将重新创建新的日志文件 删除重命名日志文件。

这可以工作，但建议先备份数据库。

使用DBCC ShrinkFile ({logicalLogName}， TRUNCATEONLY)命令。如果这是一个测试数据库，并且您试图节省/回收空间，这将有所帮助。

记住，TX日志确实有一个最小/稳定状态大小，它们将逐渐增长。根据您的恢复模型，您可能无法收缩日志-如果是FULL且您没有发布TX日志备份，则日志不能收缩-它将永远增长。如果不需要TX日志备份，请将恢复模式切换为Simple。

记住，在任何情况下都不要删除日志(LDF)文件!您几乎会立即破坏数据库。煮熟的!完成了!数据丢失!如果“未修复”，主MDF文件可能会永久损坏。

永远不要删除事务日志-你会丢失数据!你的部分数据在TX日志中(不管哪种恢复模式)…如果分离并“重命名”TX日志文件，将有效地删除数据库的一部分。

对于那些已经删除了TX日志的用户，您可能希望在丢失更多数据之前运行一些checkdb命令并修复损坏。

看看保罗·兰德尔关于这个话题的博客文章，糟糕的建议。

此外，一般不要在MDF文件上使用收缩文件，因为它会严重破坏你的数据。查看他的坏建议部分以获得更多信息(“为什么你不应该缩小你的数据文件”)

看看保罗的网站，他讨论了这些问题。上个月，他在他的“一天的神话”系列文章中探讨了许多这样的问题。