我已经读过很多文章，不建议缩小数据库规模，因为这样做会导致碎片化，从而降低性能。
ref：
https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/
https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/
但是，对于数据文件来说似乎是这样，如果日志已满，收缩日志应该不是问题吧？
如果数据文件很大，需要很多空间，我确实需要更多空间来插入和更新一些新数据，缩小显然减小了驱动器上文件的大小，我以为我可以使用免费的插入新数据的空间。但是如果不建议缩小，该如何解决？何时才是最好的使用收缩方法
答案 0 :(得分：1)
如果数据文件很大且占用大量空间，我确实需要更多 插入和更新一些新数据的空间，缩小显然减少了 驱动器上文件的大小，我以为我可以使用 可用空间来插入新数据。
如果您的数据文件占用大量空间，并不表示此空间为空。
您应使用sp_spaceused确定数据文件中是否有未使用的空间。
如果有未使用的空间，则将已使用“用于插入和更新一些新数据”，如果没有 >做shrink不会有任何改变：shrink不会删除您的数据，它所做的只是将数据移到文件的开头以在末尾留出空间以便将其返回给{{1 }}。
当您的数据文件为2Tb且删除了1 Tb数据并且您不打算在未来10年内再插入另一Tb数据时，收缩数据文件可能很有用。
您可以将OS想象成1m x 1m x 1m的盒子。如果装满玩具的盒子只有一半，即使您不使用data file，也可以将其他玩具放入此盒子（制作shrink / insert）。相反，update所做的是，它将所有玩具收集在一个角上，然后将其切开以使其尺寸为50cm x 50cm x 50cm。这样，您的房间（OS）现在具有更多的可用空间，因为您的toyb盒仅占用收缩之前所用空间的一半。
...如果您的盒子已经满了，即使尝试做shrink，也无法添加更多玩具。
如果日志已满，收缩日志应该不是问题吧？
shrink是另一个过程，Shrinkig log内什么也不能移动，从这个意义上说，log file不会像shrink那样造成太大危害：不需要服务器资源，不会造成任何碎片等。
但是，是否成功取决于您的“日志已满”的原因。
如果由于data file您的日志已满，则缩小的日志文件将不会更改任何内容：保留日志以使您拥有full model（或使{{1}成为可能） }或log backup chain等。
相反，如果您的数据库mirroring是log shipping，并且recovery model长时间打开存在问题，或者simple很大（也许使用完整日志记录，例如transaction而不包含data loading），并且您的insert into变得比tablock大，并且您发现并解决了该问题，因此不需要巨大的log file，是的，您可以将其缩小到合理的大小，并且无害。