这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：
在 SQL Server 中 -
- 事务日志变得如此之大的一些原因是什么？
- 为什么我的日志文件这么大？
- 有什么方法可以防止这个问题的发生？
- 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？
sql-server shrink transaction-log auto-growth recovery-model
我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？
如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？