非聚集索引的性能和大小随着聚集键大小的增加而下降？答案

【问题标题】：Performace and Sizes of Non-Clustered Indexes drops as size of clustering key increases?非聚集索引的性能和大小随着聚集键大小的增加而下降？
【发布时间】：2010-01-25 11:46:33
【问题描述】：

摘自：http://www.sqlservercentral.com/articles/Indexing/68563/

聚类键的宽度但是，不仅影响聚集索引。聚类键，作为行的地址，位于每一个非聚集索引。因此广泛的聚类键增加了所有非聚集索引的大小，也降低了他们的效率

如果sizeof(int *)和sizeof(char *)一样，为什么非聚集索引中指向数据页的指针的大小要增加。还是有其他一些我不知道的寻址机制？

【问题讨论】：

标签： sql-server pointers indexing

【解决方案1】：

指针不指向数据页：它指向聚集索引。微妙，但与没有聚集索引的情况不同，其中每个 NC 索引条目都指向数据页中的行 ID (RID)。

因此，如果您将char(10) 作为您的键，则每个 NC 索引条目都有一个 10 字节的指针。如果你有整数，那么它是 4 个字节。

对于 char 与 int，还有其他注意事项：至少排序规则（确定大小写、重音、假名和宽度敏感度）。

您的 4 字节字符串仅适用于 char(4)。 nchar(4) 是 8 个字节，varchar(4) 是 2 到 6 个字节（2 字节长度），nvarchar(4) 是 2 到 10 个字节。

【讨论】：

没错，它确实指向存储在聚集索引的叶子中的数据页。无论存储的数据类型是 int 还是 char，该指针的大小都是相同的。请注意，我不是在这里谈论 sizeof(int) 而是 sizeof(int *) 这是指针地址值
没有指针是聚集键的长度。这不是 c++：它是一个数据结构

【解决方案2】：

在聚簇表中，聚簇键的值是行指针，因此隐式附加到每条记录。

如果(col1, col2, col3) 是聚集键，那么col4 上的索引实际上就是(col4, col1, col3, col3) 上的索引。

它的大小当然取决于col1、col2和col3的大小。

【讨论】：

不，不是。 col1、col2、col3 仅包含在 col4 上索引的叶级别。不在该指数的任何中间水平。但出于所有实际目的... :-)
@Frank Kalis: 你想说如果我们有1,000,000页的主键并且col4的唯一值是1，那么我们将有一个根节点和@ 987654331@叶节点？
如果 1 是 col4 的唯一值，我会认真地重新考虑我的索引策略...但是不，这不是我要说的。不要将叶节点与叶行混淆。由于 {col1, col2, col3} 对于每一行的定义都是不同的，并且它们构成了聚集索引，因此 col4 上的索引中它们的条目必须与表中的行一样多。 col4 上的索引肯定只有 1 个根级别，有 1,000,000 个叶级行和索引深度 > 2。
@Frank Kalis：请注意，我没有写“1,000,000 记录”，我写了“1,000,000 页面价值 PRIMARY KEYs”。这意味着我们将拥有1,000,000 叶级页面（不是记录）。那么中间索引级别中存储了什么？
啊，我现在明白你的意思了，我必须承认我成功地把自己弄糊涂了。聚集索引的中间级别上的条目包含键值以及指向另一个中间级别上的另一个索引行的指针或指向叶级别上的数据行的指针。对于非聚集索引，每个索引行都包含键值和行定位符，行定位符可以是聚集索引键（如果存在聚集索引）或表是堆时的 RID。