SQL Server 聚集索引：（物理）数据页顺序答案

【问题标题】：SQL Server Clustered Index: (Physical) Data Page OrderSQL Server 聚集索引：（物理）数据页顺序
【发布时间】：2011-02-13 07:41:24
【问题描述】：

我很难理解 SQL Server 2005 中的聚集索引是什么。我阅读了 MSDN 文章 Clustered Index Structures（以及其他内容），但我仍然不确定我是否理解正确。

（主要）问题是：如果我将一行（带有“低”键）插入到带有聚集索引的表中会发生什么？

上面提到的 MSDN 文章指出：

数据链中的页面和其中的行按照聚集索引键的值排序。

例如Using Clustered Indexes 声明：

例如，如果将一条记录添加到靠近顺序排序列表开头的表中，则表中该记录之后的任何记录都需要移动以允许插入记录。

这是否意味着如果我将具有非常“低”键的行插入到已经包含大量行的表中，所有行都在磁盘上物理移动？我不能相信。这需要很长时间，不是吗？

或者（我怀疑）是否有两种情况取决于第一个数据页的“完整”程度。

A) 如果页面有足够的可用空间来容纳记录，则将其放置到现有数据页面中，并且数据可能会（物理上）在该页面内重新排序。
B) 如果页面没有足够的可用空间来记录，则会创建一个新数据页面（磁盘上的任何位置！）并“链接”到B 树？

这意味着数据的“物理顺序”仅限于“页面级别”（即在数据页面内），而不是位于物理硬盘驱动器上连续块上的页面。然后，数据页就会以正确的顺序链接在一起。

或者以另一种方式表述：如果 SQL Server 需要读取具有聚集索引的表的前 N 行，它可以顺序读取数据页（按照链接）但这些页不是（必须）在磁盘上按顺序逐块（因此磁盘头必须“随机”移动）。

我离我有多近？ :)

【问题讨论】：

标签： sql-server sql-server-2005 indexing clustered-index

【解决方案1】：

如果您碰巧插入了一个 ID 为“低”的行，那么是的 - 它将被放置在您已经存在的具有相似 ID 的其他行的附近。

如果您的 SQL Server 页面（8K 块）被填充到最大，则将发生 页面拆分 - 一半的行将保留在该页面上，另一半将移动到新的一页。这两个新页面现在将有一些新行的容量。

这就是为什么您不想使用非常随机的东西作为集群键的原因之一，例如一个 GUID，这将导致在整个地方插入行。

试图避免页面拆分（这是非常昂贵的操作）是大师喜欢 Kimberly Tripp heavily advocate using something that is ever increasing 作为您的集群键的主要原因之一 - 例如一个 INT IDENTITY 列。在这里，始终保证新值大于数据库中已有的任何值，因此始终在食物链的“末端”添加新行。

有关更多优秀背景信息，请参阅 Kimberly Tripps 的博客 - 尤其是她的 Clustering Key 类别！

【讨论】：

【解决方案2】：

你有多近？非常！

这些文章可能有助于巩固您的理解：

http://msdn.microsoft.com/en-us/library/aa964133(SQL.90).aspx

http://www.sql-server-performance.com/articles/per/index_fragmentation_p1.aspx

【讨论】：