由于我对Stack Overflow上的所有答案都不是真正满意的，包括投票最多的建议，并且由于我想解决Mike的答案不正确的几件事，我想我会提供我的输入也在这里。我也把这个答案的副本放在了那里。
对于遇到意外增长（您不希望再次发生这种情况）的情况，应该真正减小日志文件的大小。如果日志文件将再次增大到相同的大小，则暂时缩小将不会有太多效果。现在，根据数据库的恢复目标，这些是您应该执行的操作。
首先，进行完整备份
如果发生问题，请务必对数据库进行任何更改，否则请确保无法还原数据库。
如果您关心时间点恢复
（通过时间点恢复，我的意思是您关心的是能够还原到除完整备份或差异备份以外的任何内容。）
大概您的数据库处于FULL恢复模式。如果没有，请确保它是：
ALTER DATABASE yourdb SET RECOVERY FULL;
即使您进行常规的完整备份，日志文件也会不断增长，直到执行日志备份为止-这是为了保护您，而不是不必要地吞噬了磁盘空间。根据恢复目标，您应该非常频繁地执行这些日志备份。例如，如果您有一条业务规则规定在发生灾难时可以承受不少于15分钟的数据丢失损失，则您应该有一份每15分钟备份一次日志的作业。这是一个脚本，它将根据当前时间生成带有时间戳的文件名（但是您也可以使用维护计划等来执行此操作，只是不要在维护计划中选择任何收缩选项，它们太糟糕了）。
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
请注意，它\\backup_share\应该在代表不同基础存储设备的另一台计算机上。将这些备份到同一台计算机（或使用同一基础磁盘的另一台计算机，或同一物理主机上的另一台VM）并不能真正帮助您，因为如果计算机崩溃，您将丢失数据库和它的备份。根据您的网络基础架构，在本地备份然后将其转移到幕后的其他位置可能更有意义。无论哪种情况，您都希望尽快将它们从主数据库计算机中删除。
现在，一旦您运行了常规的日志备份，就应该将日志文件压缩到比现在炸毁的文件更合理的大小。但这并不意味着运行SHRINKFILE，直到日志文件为1 MB一遍又一遍-即使你经常备份日志，它仍然需要适应可能出现的任何并发事务的总和。日志文件自动增长事件非常昂贵，因为SQL Server必须将文件归零（与启用即时文件初始化时的数据文件不同），并且用户事务必须等待这种情况发生。您希望尽可能少地执行此增长-收缩-增长-收缩例程，并且您当然不想让用户为此付费。
请注意，可能需要收缩两次日志才能进行收缩（感谢Robert）。
因此，您需要为日志文件提出一个实际的大小。没有人可以在不了解系统的情况下告诉您那是什么，但是如果您经常收缩日志文件并且又在增长，那么一个好的水印可能比最大的水印高10-50％。 。假设这是200 MB，并且您希望任何后续的自动增长事件为50 MB，那么您可以通过以下方式调整日志文件的大小：
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
请注意，如果日志文件当前> 200 MB，则可能需要先运行此文件：
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
如果您不关心时间点恢复
如果这是一个测试数据库，并且您不关心时间点恢复，则应确保数据库处于SIMPLE恢复模式。
ALTER DATABASE yourdb SET RECOVERY SIMPLE;
将数据库置于SIMPLE恢复模式将确保SQL Server重用日志文件的某些部分（实质上逐步淘汰不活动的事务），而不是增加以保留所有事务的记录（就像FULL恢复一样，直到备份日志为止）。CHECKPOINT事件将有助于控制日志，并确保它不需要增长，除非您在CHECKPOINTs 之间生成了很多t-log活动。
接下来，您应该绝对确保此日志增长确实是由于异常事件（例如，每年一次的春季大扫除或重建最大的指标），而不是由于日常的日常使用。如果将日志文件缩小到一个可笑的小尺寸，而SQL Server只需要再次增大它以适应您的正常活动，那么您获得了什么？您是否能够利用您只是暂时释放的磁盘空间？如果需要立即修复，则可以运行以下命令：
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO
否则，请设置适当的大小和增长率。按照时间点恢复情况下的示例，您可以使用相同的代码和逻辑来确定合适的文件大小并设置合理的自动增长参数。
一些你不想做的事
使用TRUNCATE_ONLYoption 备份日志，然后选择SHRINKFILE。例如，此TRUNCATE_ONLY选项已被弃用，并且在当前版本的SQL Server中不再可用。其次，如果您处于FULL恢复模式，这将破坏您的日志链，并需要新的完整备份。
分离数据库，删除日志文件，然后重新附加。我不能强调这有多危险。您的数据库可能无法备份，可能会被怀疑备份，可能必须还原到备份（如果有），等等。
使用“缩小数据库”选项。DBCC SHRINKDATABASE使用维护计划选项执行相同操作是个坏主意，尤其是在您只需要解决日志问题的情况下。定位您要调整的文件，并使用DBCC SHRINKFILE或ALTER DATABASE ... MODIFY FILE（上述示例）分别进行调整。
将日志文件缩小到1 MB。这看起来很诱人，因为，在某些情况下，SQL Server将允许我执行此操作，并查看它释放的所有空间！除非您的数据库是只读的（并且应该使用标记ALTER DATABASE），否则这绝对会导致许多不必要的增长事件，因为无论恢复模式如何，日志都必须容纳当前事务。暂时释放该空间的目的是什么，以便SQL Server可以缓慢而痛苦地收回该空间？
创建第二个日志文件。这将暂时缓解已满磁盘的驱动器，但这就像试图用创可贴修复被刺破的肺部一样。您应该直接处理有问题的日志文件，而不是仅添加另一个潜在的问题。除了将某些事务日志活动重定向到其他驱动器之外，第二个日志文件确实对您没有任何作用（与第二个数据文件不同），因为一次只能使用其中一个文件。保罗·兰德尔（Paul Randal）也解释了为什么以后会有多个日志文件咬你。
主动
与其将您的日志文件缩小到少量并让它自己不断以很小的速度自动增长，不如将它设置为一个相当大的大小（一个可以容纳您最大并发事务集的总和）并设置一个合理的自动增长设置为后备，这样它就不必多次增长就可以满足单个交易，因此在正常业务运营期间必须不断增长的情况相对很少。
这里最糟糕的设置是1 MB增长或10％增长。有趣的是，这些是SQL Server的默认值（我抱怨过，要求更改无用）-数据文件1 MB，日志文件10％。前者在当今时代太小了，后者每次导致的事件越来越长（例如，您的日志文件为500 MB，第一个增长为50 MB，下一个增长为55 MB，下一个增长为60.5 MB等等。-在慢I / O上，相信我，您会真正注意到此曲线）。
进一步阅读
请不要在这里停下来；尽管您看到的有关缩小日志文件的许多建议本质上都是不好的，甚至可能造成灾难性的影响，但有些人更关心数据的完整性而不是释放磁盘空间。
