sql-server - SQL Server 聚集索引 : (Physical) Data Page Order

Question

我正在努力理解 SQL Server 2005 中的聚集索引是什么。我读了 MSDN 文章 Clustered Index Structures (除其他外)但我仍然不确定我是否理解正确。

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

上面提到的 MSDN 文章指出:

The pages in the data chain and the rows in them are ordered on the value of the clustered index key.

和 Using Clustered Indexes例如声明:

For example, if a record is added to the table that is close to the beginning of the sequentially ordered list, any records in the table after that record will need to shift to allow the record to be inserted.

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

或者更确切地说(正如我怀疑的那样)有两种情况取决于第一个数据页的“完整”程度。

A) 如果页面有足够的空闲空间来容纳记录，则将其放入现有数据页面中，并且数据可能会(物理上)在该页面内重新排序。

B) 如果页面没有足够的可用空间用于记录，将创建一个新的数据页面(磁盘上的任何位置!)并“链接”到 B 树的叶级的前面？

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

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

我有多近？ :)

Answer 1

如果您碰巧像您说的那样插入了具有“低”ID 的行，那么是的 - 它将被放置在已经具有类似 ID 的其他行的附近。

如果您的 SQL Server 页面(8K 块)已填满，则会发生页面拆分——一半的行将保留在该页面上，另一半将移动到新页面。这两个新页面现在将有一些新行的容量。

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

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

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