重建索引，数据库现在的大小是原来的10倍

我有一个大约15演出的SQL Server数据库（2008 R2 SP1）。事实证明，维护已经有一段时间没有运行了，所以我创建了一个维护计划来重建所有索引，它们非常分散。

这项工作完成了，碎片消失了，但是现在数据库已超过120个演出！我知道它会使用额外的空间来进行所有重建，但是既然工作已经完成，我认为所有空间都是可用空间，但是可用空间仅显示为3个演出，因此正在使用117个演出即使索引重建作业已完成。

我很困惑，可以使用一些指导，我已经将数据库恢复到合理的大小，我们没有足够的磁盘空间。

提前致谢！

这是发布的两个查询的结果：

log_reuse_wait_desc没有

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

第3个文件是.ndf文件，该文件仅在未使用的空间中显示3688，但是在111289中的存储量约为15 gigs。

同时，我只是弄清楚了这件事，总的是打。我已经表明我认为在重建工作中的填充因子为90，但是它的措辞是“将可用空间百分比更改为”，因此在其中使用90值，实际上是在使用填充因子10！DOH。难怪它增长了10倍。我将使用正确的填充因子进行重建，然后缩小。感谢大家的投入。

重建索引会导致数据库中额外的松弛空间。这是重新编制索引过程的自然副产物-服务器正在与当前版本一起构建索引的新的，希望是连续的版本，然后在完成时删除当前版本。

重新索引后的收缩毫无意义！

您将只重新索引索引！缩小通过在数据库内重新分配数据来消除空闲空间。

这是Paul Randal的一篇不错的文章，他在Microsoft工作时负责DBCC代码（包括收缩），说明了为什么不应该收缩。

您应该使用过rebuild选项SORT_IN_TEMPDB=ON。

在您的情况下，实际的数据文件（所讨论的表所在的位置）已用于对索引进行排序。120GB的空间大部分仍未使用，并在需要时填充页面数据。

您可以通过此查询查看使用/可用空间状态（从此处获取）：

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

要缩小特定的数据库文件（数据或日志），可以在此处查看一些信息。之前的警告是，释放100+ Gb数据库需要花费相当长的时间（还取决于存储速度），释放未使用的空间，所以就让它运行。

如果没有其他详细信息，我怀疑您需要进行事务日志备份，然后才能收回其空间。

看看会select name, log_reuse_wait_desc from sys.databases告诉你什么。如果log_reuse_wait_desc列中的内容如此，LOG_BACKUP那么它只有在完成tran日志的备份后才能回收空间。