在删除了大量数据后，收缩+重新索引是否很糟糕？

Question

我有一个运行在SQLServer2017 Express上的测试环境，它只使用最近的数据(作业每个月删除一次超过三个月的数据)。

这项工作做了以下工作：

1. 使用while循环，它删除了三个月以上的数据。
2. 如果数据库的大小超过某个阈值，则收缩它。
3. 重新索引所有表

这篇文章描述了由于索引碎片而收缩数据库是多么糟糕，以及为什么重新索引也需要额外的空间。

最后一次运行是从9GB数据库开始的。删除图克斯3-4分钟，并重新索引大约30秒。数据库减少到大约5GB。

因为这是一个测试环境，所以我可以在没有任何问题的情况下支付这个停机时间。

问题:在删除了大量数据后，收缩+重新索引会有什么不好吗？

Answer 1

那么，问问自己:收缩的意义是什么，如果您知道重新索引(以及任何其他数据更改，真的)会在收缩之后再次展开文件？

即使重新索引没有使其恢复到9GB，如果数据库将来会增长，我也认为临时回收一些磁盘空间的值绝对为零。在数据库再次增长之前，您将如何处理这个空间？租出去然后驱逐他们？这就像一家餐馆每次顾客起身离开时都会拆开一张桌子，但当一位新顾客到来时，却重新组装了它。

在您的情况下(您需要将数据文件保持在10 5GB以下，因为您选择了许可，而没有其他原因)，仅为了重新增长到9GB就没有必要降低到5GB。当数据文件再次返回到9GB空间时，我希望有一些活动监视器警告您(或者将它保持在9GB!)实际使用的空间接近9GB。

与其把它看作是“保持过去三个月”的要求，不如把它看作是“保持9GB的数据”的要求。当每个时间段(日/周/任何其他时间)的数据量增加时，您将不得不重新查看它。当你在三个月内积累了超过10 of的数据时，会发生什么？

Answer 2

既然这是一个测试环境，为什么不能使用SQL2017开发人员呢？然后，您将不会受到10 of限制的限制，从而减少删除记录的需要。