我有一个数据库，其大小增长非常快。目前它的大小约为 60GB，但是在执行 db_spaceused 存储过程之后，我可以验证有超过 40GB 未使用（未使用的空间不同，我理解的不是保留空间用于表增长）。实际数据大小约为 10-12 GB，保留空间中只有几 GB。
现在为了收集未使用的空间，我尝试使用收缩操作，但结果没有帮助。进一步搜索后，我还发现不要使用收缩数据库，因为这会导致生成数据片段，从而导致磁盘操作时的延迟。现在我真的不确定我应该尝试什么其他操作来重新收集空间并重新收集数据库。我不知道由于大小查询可能需要比预期更长的时间，并且回收这个空间可能有助于提高性能（不确定）。
在调查时，我还遇到了 Gererate Scripts 功能。它也有助于导出数据、模式，但我不确定它是否也有助于创建脚本（每个用户、权限和其他东西），这样脚本将帮助创建数据库的副本（深拷贝/克隆），然后使用 create scema将数据填充到其他数据库/服务器？
任何指针都会有所帮助。
如果您的数据库是 60GB，则意味着它已增长到 60GB。即使数据只有 20Gb，您也可能有不时增加数据的操作（例如，夜间索引维护作业）。建议将数据库保留为 60Gb。不要试图回收空间，你只会造成伤害，并且任何导致数据库增长到 60Gb 的事情都可能再次发生并触发数据库增长。
其实你应该反其道而行之。尝试找出它增长到 60Gb 的原因，并推断当您的数据达到 30Gb 时会发生什么。数据库会增长到 90Gb 吗？如果是，您现在应该将其增加到 90Gb。您最不想看到的就是随机增长，并且可能在关键时刻耗尽磁盘空间。事实上，您现在应该检查您的服务器是否启用了即时文件初始化。
当然，现在的问题是：什么会导致 3 倍的数据量增长，以及如何识别它？我不知道有什么简单的方法。我建议从查看您的 SQL 代理作业开始。检查您的维护脚本。查看应用程序本身，它是否具有数据增长和删除的模式？查看过去的备份（您确实拥有它们，对吗？）并进行比较。
顺便说一句，我假设进行了尽职调查，并且您检查了数据文件是否已增长到 60Gb。如果是 LOG 文件已经增长那么容易，这意味着您启用了完全恢复模式并忘记备份日志。