聚集索引占用很大的空间

Question

我一直在为一个处理历史数据的数据库建立索引，最近遇到了一个令我惊讶的聚集索引问题。

数据库为Server 2018。该表本身处理帐户信息，本质上是一个事实表，每天填充约200条记录，并有200列。目前，它正处于6800万个记录，在索引之前，它占据了大约120 of的空间。

由于它是帐户信息上的历史表，而且我们没有UUID的设置(这将是我的老板告诉我不要花时间处理这个数据库的巨大努力)，所以我在Date字段和account Number上创建了主键+聚集索引，其语句相当于：

ALTER TABLE AcctHistory 
ADD CONSTRAINT PK_AcctHistory PRIMARY KEY CLUSTERED (Date, Account_Number)

日期字段是一个日期时间字段(这是我没有设置但现在正在构建的DEV环境。只需知道我计划将其更新到一个日期，但我提供的类型是相关的。)，Account_Number字段是一个bigint。

在运行此语句之后，根据SSMS磁盘空间按表报告，表所消耗的空间的数量高达480 by，是索引前的4倍。

我知道索引占用空间，但我从未听说过这样的情况。这是正常的，还是意味着我可以解决一个节省空间的问题？

Answer 1

将表从堆更改为群集表并不能“增长数据”。也就是说，与堆相比，聚集索引不需要更大的空间，仅仅因为它被组织为一个链接列表(按某些列组合排序)。

然而，需要注意的是：

内部碎片(不足100%整页)。如果为实例(sp_configure)配置了一个很低的填充因子值，或者在CREATE /ALTER命令中指定了一个低值，那么这可以解释它。因此，使用sys_dm_db_index_physical_stats()检查您的页面是否完整。

如果你拿苹果和橘子比较的话。您是只查看聚集索引还是在表级别(即，包括所有其他索引)。其他索引(非聚集，NC)将堆的RID作为“行指针”，为8字节。群集表的NC索引中的行指针是群集键。在你的例子中，它是16个字节(如果它不是唯一的，那么它将是额外的4个字节)。也就是说，NC索引现在将比以前大一点。另外，然后将表从堆转换为聚集索引，所有NC索引都重新生成，我认为填充因子将从服务器设置中提取。这能解释吗？我很怀疑，但也许在某些极端的情况下.假设在进行比较时包含NC索引大小。因此，确保您看到的是正确的东西(我更喜欢我的sp_indexinfo，它给出了相当详细的输出，但是提供了任何您知道的信任)。

我赌的是sp_configure的填充因子很低.