【问题标题】:For insert-performance consideration, should a clustered index on a timestamp be ascending or descending?出于插入性能考虑,时间戳上的聚集索引应该是升序还是降序?
【发布时间】:2010-09-01 02:01:08
【问题描述】:

我刚刚意识到我在 Timestamp 上有一个以降序排列的聚集索引。我正在考虑将其切换为升序,以便在插入新的、不断增加的时间戳时,将它们添加到表的末尾。就目前而言,我怀疑它必须在表的开头添加行,我想知道 SQL Server 是如何处理的。

它是否可以在表的开头有效地分配新页面,并有效地将新行插入这些页面,或者按照时间戳的顺序填充页面并在末尾分配新页面以升序聚集更好索引。

【问题讨论】:

    标签: performance sql-server-2008 sorting insert clustered-index


    【解决方案1】:

    其实加在开头和结尾都是一样的

    页面填满,页面拆分,分配新页面...

    新页面可能是连续的,也可能不是连续的,无论它是在开头还是结尾。这就是为什么您定期运行 ALTER INDEX 等。

    在实践中,聚集索引的 ASC/DEC 顺序对于 SELECT/ORDER BY 更重要...尽管我在 SQL Server 2005 及更高版本中注意到这一点的情况较少。

    【讨论】:

    • 我以为正好相反。我的理解是,选择/排序依据并不重要,因为它可以反向使用索引。但这对于插入很重要,因为在填充单个页面时,它会对信息进行物理排序,因为它是一个聚集索引。我想我真正感兴趣的是页面如何填满,以及当以升序插入项目时,升序或降序是否会影响单个页面的填满方式。
    • 我担心使用降序聚集索引......每次我插入一个新的时间戳时,它都必须移动活动页面的内容以首先对新条目进行排序(因为它在物理上排序行降序)。
    • 数据仅在创建和重建时按物理顺序排列。它没有通过 INSERTS 和 UPDATES 进行物理维护:它是逻辑上维护的,这就是需要定期维护索引的原因。如果 ORDER BY 与 INDEX 排序相反,那么您可以添加工作:当排序对齐时,我已经看到 IO 双(或一半)
    猜你喜欢
    • 2012-09-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-31
    • 2016-09-14
    • 2012-06-25
    • 1970-01-01
    相关资源
    最近更新 更多