使用收缩 SQL Server 的最佳做法是什么？

Question

我读过很多，不推荐使用收缩数据库的做法，因为它会导致碎片化，从而导致性能下降。

参考：

https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/

https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/

但是，数据文件似乎是这样，如果日志已满，那么缩小日志应该不是问题吧？

如果数据文件很大，占用大量空间，我确实需要更多空间来插入和更新一些新数据，缩小显然会减少驱动器上文件的大小，我认为我可以使用免费的插入新数据的空间。但如果不建议缩小，我该如何解决？什么时候最好使用收缩

Answer 1

如果数据文件很大，占用大量空间，我确实需要更多 插入和更新一些新数据的空间，明显缩小 驱动器上文件的大小，我认为我可以使用 插入新数据的可用空间。

如果您的数据文件占用大量空间，这并不意味着该空间为空。

您应该使用sp_spaceused 来确定数据文件中是否有未使用的空间。

如果有未使用的空间，它将已经用于“插入和更新一些新数据”，如果没有 > 做shrink 不会改变任何事情：shrink 不会删除您的数据，它所做的只是移动文件开头的数据以在末尾腾出空间，以便将其返回给OS。

当您有一个 2Tb 的数据文件并删除了 1Tb 的数据并且您不打算在未来 10 年内插入另一个 Tb 数据时，收缩数据文件会很有用。

您可以将您的data file 想象成一个 1m x 1m x 1m 的盒子。如果你只有一半的盒子装满了玩具，即使你不使用shrink，你也可以把其他玩具放进这个盒子里（制作insert/update）。而shrink 的作用是将所有玩具聚集在一个角落，然后切割你的盒子以使其尺寸为 50 厘米 x 50 厘米 x 50 厘米。这样，您的房间 (OS) 现在就有了更多可用空间，因为您的玩具盒只占用了缩小前一半的空间。

...如果您的盒子已经满了，即使您尝试做shrink，也无法添加更多玩具。

如果日志已满，缩小日志应该不是问题吧？

Shrinkig log 是另一个进程，在log file 内部不能移动任何东西，从这个意义上说，shrink 当然不会像data file 那样造成太大的伤害：它不需要服务器资源，它不需要造成任何碎片等。 但是是否成功取决于您的“日志已满”的原因。

如果您的日志因full model 已满，则缩小日志文件不会改变任何内容：保留日志以使您有可能拥有log backup chain（或使mirroring 或log shipping 成为可能等）。

如果您的数据库 recovery model 是 simple，并且长时间打开的 transaction 存在一些问题，或者存在巨大的 data loading（可能有完整的日志记录，例如 @ 987654343@ 没有tablock) 并且你的log file 变得比data file 大，你发现并解决了这个问题，你不需要这么大的log file，是的，你可以将它缩小到合理的大小，并且它没有害处。