说到聚集索引，我想每个码农都明白，但是也有很多像我这样的猥程序员，只能用死记硬背来解决这个问题，什么表中只能建一个聚集索引，
然后又扯到了目录查找来帮助读者记忆。。。。问题就在这里，我们不是学文科，，，不需要去死记硬背，，，我们需要的就是能看到在眼里面的
真实东西。。。。。我们都喜欢聚集索引，因为它能够把无序的堆表记录变成有序，还玩起了B树。。。这样就把复杂度从N降低到了LogMN。。。
这样的话逻辑读，物理读就下来了。
一：现象
1：无索引的情况
还是老规矩，看个例子感受下，首先我有一个Product表，里面没有任何索引，如下图：
从上图中，我悲剧的看到了，物理读是9次，也就说明走了9次硬盘，你也可以想到，走硬盘的目的是为了拿数据，逻辑读有1636次，要注意的是这里
的”次“是“页”的意思，也就是在内存中走了1636个数据页，我用dbcc ind 给你看一下，是不是有1636个表数据页。
这里有1637个数据页的原因是第一个是IAM跟踪页。
2：有聚集索引的情况
下面我在Product表中建一个product_idx_productid的聚集索引，然后再次看看io情况，如下图：
当你看到这个”逻辑读“为3次的时候，你是不是已经疯了。。。在多达1636个数据页中找到目标数据，只需3次。。。。这个在算法盲看来是不是神
仙下凡？？？当然，，，此物天上有，人间也有。。。既然有，就应该有一种非常强烈的探索欲。。。。看看这里面到底是怎么玩的。。。。。。
二：探索原理
1： 探索叶子节点
刚才也说了，聚集索引玩的就是B树，既然是B树，那就有叶子节点和分支节点，专业术语就是度为0的为叶子节点，度>0的叫做分支节点。。。。
我想你也听说了，聚集索引是将索引列数据进行排序后放入B树，那为了让你眼见为实，我先建立一个ID无序的3条记录。
insert into Person values(2,'bbbbb')insert into Person values(3,'ccccc')insert into Person values(1,'aaaaa')
然后我用dbcc ind 命令查看下3条记录在哪个数据页中，如图：
从图中可以看到，我的三条记录是放在148号数据页中的，然后我导出148号数据页，看看内容是什么。
dbcc traceon(3604)dbcc page(Ctrip,1,148,1)
从上图中，我们看到了”数据页“中的各个槽位的指向是按照表中的实际存储记录来的，好了，下面我创建个聚集索引，看看实际数据是不是真的有序了？
create clustered index Ctrip_idx_ID on Person(ID)
不过在这里有个有趣的问题，我的148号”表数据页“哪去了？？？也是够奇葩的，换来的确实173号索引页，那为了保证数据完整性，应该是把
148号数据页的内容灌到173索引页里面去了吧？？？？ 没关系，验证一下。
1 dbcc traceon(3604)2 dbcc page(Ctrip,1,173,1)
通过上面的图，有没有直观的感觉到？ 数据现在已经是aaaaa,bbbbb,ccccc的模式了。。。有序啦。。。。同时索引页中也保存了148号数据
页的字段值，比如ID，Name信息，拿下面的slot0槽位举例：
到此为止，我想你对叶子节点的内容有了个大概的认识，起码没有让你死记硬背了~~~
2 ：探索分支节点
为了让你看到分支节点，我得多灌一些数据进去，好歹要让数据撑破一个索引数据页，这样分支节点索引数据页就出来了，看下面的例子：
从图中可以看到，当我插入1000条数据的时候，已经出现了一个分支节点（120号索引数据页），三个叶子节点（173,121，126），叶子
节点的数据页内容我也说过了，现在我很好奇”分支节点“中保存着什么内容？？？我好兴奋，我要导出120号索引数据页了。。。
1 dbcc traceon(3604)2 dbcc page(Ctrip,1,120,1)
简单分析下slot0：06000000 00ad0000 000100 的内容
00000000：叶子索引页中的最小key值（这里有点特殊，除一行记录不是保存最小值以外，其余都是的），转换为十进制就是0。
ad000000：叶子索引页的页号，转换为十进制就是173。
0100：叶子索引页的文件号，转换为十进制就是1.
不过通过分析，我们看到了，其实分支节点中保存着有两个值，一个childpage的minkey，一个childpage的pageid，同理，其他的槽位也是这样。
我们换个参数命令，让结果更直观点，记录中就是保存着”pageID“和”minKey“。
这样的话，我脑海中就有一张图出来了，不知道你现在是否有了？？？？
通过上面的分析，除了第一行记录不是保存子索引页中最小key的值外，其他记录都是提取子索引页中的最小索引键值，这一点要注意。。。
也许对sqlserver团队来说，只要判断小于449的话就直接去(1:173)数据页，小于889的直接去(1:121)数据页就可以啦。。。
当你看到这里的时候，不知道你是否已经明白，为什么表中只能有一个聚集索引呢？？？好了，乱鸡巴扯了好多，希望对你有所帮助。
分类: sql server
荣誉：推荐博客
12
0
(请您对文章做出评价)
« 上一篇：Sql Server之旅——第二站 理解万恶的表扫描
» 下一篇：Sql Server之旅——第四站 你必须知道的非聚集索引扫描
posted @ 2015-01-18 00:05 一线码农 阅读(1404) 评论(14) 编辑 收藏
评论列表
学习了
@要有好的心情
感谢支持
哦哦⊙ω⊙受教了，太棒啦。
@小宝er
是的，我们需要眼见为实
底层思想 赞
@BYSocket
必须底层，只有这样上层再怎么换花样玩，都能从容应对，这些支持。
iam页是什么
@小宝er
数据页分很多种，iam页就是其中一种，用于跟踪数据页的，包括表数据页，索引数据页啦～
这文章比较实用，我决定收录到博客园非官方月刊中。上期的月刊：http://www.cnblogs.com/zzy0471/p/4212340.html
楼主想说明聚集索引存储数据的原理，我觉得从宏观上把聚集索引的B树结构描述清楚就行了，从页面内部来解释，反而是有问题的
dbcc page打印出来的信息并非数据在page中的物理顺序，他这个命令打印出来的信息其实是根据页面行偏移量来依次读取打印的，其实对聚集表做查询（不显式排序），也是根据行偏移量来一次读取数据的
页面内部存储过的不一定是这个顺序
你打印出来的Row – Offset是一次递增的，这一点没有问题，因为你一开始是堆表，插入数据后又新建了聚集索引，这一过程伴随着索引的重建，页面内部的物理顺序跟页面行偏移量是一样的
我新建跟你一样的表，先建立聚集索引，再插入数据，然后删除中间的任意一条数据（比如插入的ID是1，2，3，删除ID=2的，再插入ID=2的数据），得到的行偏移量就是这样的
Row – Offset
2 (0x2) – 132 (0x84)
1 (0x1) – 150 (0x96)
0 (0x0) – 96 (0x60)
也就是说页面内部物理存储并非数据的顺序，顺序由行偏移量决定
参考这个
http://www.cnblogs.com/zhouqiang52154/archive/2012/11/26/2788491.html
#11楼[楼主] 2015-01-20 12:40 一线码农
@会长
帅哥会长来了呀，欢迎欢迎。
#12楼[楼主] 2015-01-20 12:40 一线码农
@wy123
你说的这个是个比较细节的问题，从数据页的构造上来说，引擎只会通过slot槽位中的offset去找data区域的实际地址，如果你用page(xxx,xxx,2)参数导出16进制的数据页，那确实容易误解出你说的这个问题，幸运在于我用page(xxx,xx,1)导出来的，这个是用slot槽位的顺序依次去看记录的实际地址，所以永远都是有序的，你可以用page(xxx,xx,1)参数导出你的slot槽位。
这里有一篇讨论聚集索引的帖子可供大家参考下：http://bbs.csdn.net/topics/390470793