我在两个不同的服务器上有一个生产数据库和一个开发数据库。这两个数据库都是从登台服务器上的同一个数据仓库提供的。有一系列自动化的 SQL 作业可以运行和填充数据库中的表。作业从 Dev 复制到 Prod，因此它们也应该相同。然而，Prod 的增长速度远远快于 Dev。
数据库中大约有 10 亿行数据。Prod 中的总数据文件大约大 123GB。总索引文件大约大 31GB。我对此很陌生，但我希望这两个数据库的大小非常相似。如果有的话，我希望 Dev 有一些额外的“垃圾”并且可能是更大的数据库。
任何想法如何找到这种尺寸差异的来源？如果需要，我可以增加 Prod 上的磁盘空间，但向我表明可能存在需要解决的问题。如果可能的话，我想收回 153GB。
诚然，在这方面我是个菜鸟，但我检查了每个环境中的 Index 文件夹，它们似乎都有一个 Index。我检查了属性，它们看起来也一样。更多索引是否也会导致数据文件大小增加？
我正在 Prod 和 Dev 中运行来自 Ola Hallengren 的 IndexOptimize 脚本，并希望它能够充分处理任何重要的碎片。我实际上并没有将任何数据从 Dev 迁移到 Prod。我们有一个托管数据的临时服务器。一组 SSIS 和存储过程将数据从登台移动到 Dev 上的数据库。更多 SSIS 作业和存储过程填充了 Dev 中的表。SSIS 和存储过程从 Dev 提升到 Prod，并在 Prod 上独立运行。Prod 作业访问与 Dev 相同的登台服务器。
压缩可能会导致您在两个表中看到相同数据的不同表和索引大小。
您在评论中询问是否有任何理由不应用压缩。页面压缩的一般权衡是您的表占用更少的空间，并且您可以以 CPU 开销为代价将更多数据放入内存。作为一个非常普遍的规则，如果您的服务器有空闲的 CPU，您不妨在应用压缩之前和之后测试您的工作负载，看看会发生什么。甚至有些工作负载在应用压缩后从 CPU 的角度来看会变得更有效率。简而言之，“视情况而定”。
不使用压缩的另一个原因是您没有获得压缩许可。您的开发服务器可能正在使用允许数据压缩的开发人员版本，但您的生产服务器可能正在使用标准版本，它在 SQL Server 2016 SP1 之前不允许数据压缩。