请注意,上面的空格只是数据,而不是索引.我正在使用Properties |下报告的值存储|一般|数据空间.
当然必须有一些开销,但每行135个字节似乎很多,特别是对于大型表.为什么会这样?还有其他人看过类似的乘数吗?哪些因素会影响所需的额外空间量?
为了比较,我尝试创建一个包含两个INT字段和1M行的表.所需的数据空间为16.4 MB:每行17个字节,而原始数据为8个字节.另一个带有INT和VARCHAR(100)的测试表填充了与真实表相同的文本,每行使用39个字节(44 K行),我希望28加一点.
因此生产表有更多的开销.这是因为它更大吗?我希望索引大小大致为N * log(N),但我不明白为什么实际数据所需的空间是非线性的.
提前感谢任何指针!
编辑:
列出的所有字段都不是NULL.真实表在VARCHAR字段和DATETIME2字段上按顺序具有聚簇PK.对于这两个测试,第一个INT是(聚集的)PK.
如果重要:该表是ping结果的记录.字段是URL,ping日期/时间和延迟(以毫秒为单位).数据会不断附加,并且永远不会更新,但会定期删除数据,以便将每个URL的每小时数量减少到几个记录.
编辑:
一个非常有趣的答案here表明,对于具有大量阅读和写作的索引,重建可能没有益处.在我的情况下,消耗的空间是一个问题,但如果写入性能更重要,那么使用松弛的索引可能会更好.
解决方法
在这些情况下,始终值得通过sys.dm_db_index_physical_stats检查碎片状态.
编辑:在评论中更新
平均页面密度(在重建聚集索引之前)为24%,这与原始问题完全吻合.页面只有1/4满,因此总大小是原始数据大小的4倍.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。