我读过很多，不推荐收缩数据库的做法，因为它会导致碎片导致性能下降。
参考：
https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/
https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/
但是，数据文件似乎是这种情况，如果日志已满，那么缩小日志应该不是问题吧？
如果数据文件很大，占用大量空间，我确实需要更多空间来插入和更新一些新数据，缩小显然会减少驱动器上文件的大小，我认为我可以使用可用空间插入新数据。但如果不建议缩小，我该如何解决？什么时候使用收缩最好
如果数据文件很大，占用大量空间，我确实需要更多空间来插入和更新一些新数据，缩小显然会减少驱动器上文件的大小，我认为我可以使用可用空间插入新数据。
如果您的数据文件占用了大量空间，这并不意味着该空间是空的。
您应该使用sp_spaceused来确定数据文件中是否有未使用的空间。
如果有未使用的空间，它将已经用于“插入和更新一些新数据”，如果没有做任何事情shrink都不会改变：shrink不删除您的数据，它所做的只是在文件开头移动数据在最后腾出空间以便将其还给OS.
当您有一个 2Tb 的数据文件并删除了 1Tb 的数据并且您不打算在未来 10 年内插入另一个 Tb 的数据时，收缩数据文件会很有用。
你可以把你想象data file成一个 1m x 1m x 1m 的盒子。如果你只有一半的盒子装满了玩具，即使你不使用shrink你也可以把其他玩具放进这个盒子里（make 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是，并且长时间打开的simplea 出现了一些问题，或者有一个巨大的（可能有完整的日志记录，例如没有）并且您变得大于，并且您发现并解决了问题并且你不需要这么大，是的，你可以把它缩小到一个合理的大小，而且它没有害处。transactiondata loadinginsert intotablocklog filedata filelog file