Azure SQL创建非聚集索引为何占用大量存储空间？

嘿，这个疑问特别常见——很多刚开始接触SQL Server（Azure SQL基于它构建）的朋友都会误以为非聚集索引只是存个指针，实际情况可比这复杂多啦。咱们一步步拆解：

核心误解：非聚集索引在聚集表中不是存物理指针 #

你的表已经有了基于主键id的聚集索引，这意味着整个表的数据是按照id的顺序物理存储的（也就是“聚集表”）。这种情况下，非聚集索引的叶节点存储的不是指向数据行的物理指针（RID），而是聚集索引的键值（也就是你的id字段）。

为什么要这么设计？因为聚集表的数据行位置可能会随着数据更新、页分裂等操作改变，但聚集键是唯一且稳定的，用它来定位数据行比物理指针更可靠——SQL Server会通过这个聚集键去聚集索引里找到对应的实际数据行，这个过程叫“书签查找”。

回到你创建的索引Index_CreatedDesc_AccountAsc，它的每个叶节点条目包含三部分：

• 你定义的索引键：Created（datetime类型，8字节） + Account（varchar类型，按实际数据平均长度计算，比如假设平均10字节）
• 聚集键：id（如果是int就是4字节，bigint的话是8字节）

光这几个字段加起来，每条索引条目就有几十字节了，5亿条记录堆下来，空间自然就上去了。

额外的空间消耗因素 #

除了索引条目本身，还有这些因素会占用空间：

• B树结构的层级开销：非聚集索引是B树结构，除了叶节点，还有上层的非叶节点用来快速导航，这些节点也会占用存储空间。
• 页开销与填充因子：每个数据页都有页头信息（大概96字节），默认填充因子是100%（页尽量填满），但即使如此，也会预留少量空间用于后续插入更新，避免频繁页分裂。
• 可能的压缩影响：如果你的聚集索引开启了数据压缩，非聚集索引可能也会继承压缩策略，这会减少一些空间，但5亿条记录的基础量级摆在这，总占用还是会很可观。

对比：堆表的非聚集索引才会存物理指针 #

如果你的表是没有聚集索引的堆表，那非聚集索引的叶节点才会存储RID（由文件ID、页ID、槽号组成，大概8字节），这种情况下索引的空间会小很多。但堆表通常不推荐在大数据量场景使用，因为容易产生碎片，查询性能也不如聚集表稳定。

总结 #

你看到的存储空间增长完全符合预期——这个非聚集索引不是只存“指针”，而是存储了索引键+聚集键的完整条目，5亿条记录的规模下，9GB左右的空间增量是合理的。

内容的提问来源于stack exchange，提问作者JakeJ