1: DBCC TRACEON
联机丛书上说，这个就是启用指定的跟踪标志，既然说指定，这个就内涵了。。。我常用来研究的只有二个：
<1> TRACEON(2588)
这个刚才你也知道了，指定了2588标记的话，你就可以看到未公开的dbcc命令了，同时你也可以看到各种命令参数的提示了。
<2> TRACEON(3604)
这个指定的标记就是可以将DBCC Page的结果显示在客户端，否则就显示不出来了，不知道你在前面几章中是否有注意到呢？？？
2：DBCC IND
这个命令在本系列中会非常频繁的使用，因为它就是用来查看”堆表“或者”索引“的数据页信息，没有它的话，我就无所研究了，还是老规矩，先看看
它的参数信息，如下图：
前两个参数我想你好理解，我在前面小节中也说到了，一个是dbname，一个是tablename or viewname or procname等等，第三个参数是最
有意思的，这里面的1，0，-1，-2 是什么意思呢？？？
<1> 1： 显示聚集索引数据页信息和IAM跟踪数据页信息。
<2> 0: 显示堆表数据页信息和IAM跟踪数据页信息。
<3>-1： 显示所有数据页信息，比如（IAM，索引数据页，堆表数据页）。
<4>-2： 显示IAM数据页信息。
<5>nonclustered indid: 从这个参数的排位列表，你大概也能看到是一个”正无限大“到1,0,-1,-2这种模式，仔细想想这个意思我想你也明白，比如
说2就代表第一个非聚集索引，3代表第二个非聚集索引，以此类推。。。。。
真不想举例子，因为再往下说的话，就说不尽了。。。算了，还是举一个例子吧：
通过上面的图，我想你应该明白我在做什么了吧？？？可以看到当前非聚集索引的数据分布在(PageFID:PagePID）(1:110) ,(1:115)....等4个数
据页上，可以看到(1:114)只是他们的数据跟踪页。有人可能会说，我怎么看出来是IAM跟踪页呢？你只需看IAMFID和IAMPID为null就可以认为是
IAM跟踪页了，当你看到IndexID>0的话，它就是索引页了。
3:DBCC PAGE
这个命令也是本系列频繁涉及到的，因为它确实太有用了，当我用IND导出数据页后，下一步就是一定要看看这个数据页中到底都有哪些信息，人
都是这样具有贪欲的，诱惑呀~~~老规矩，先看看参数。
从图中可以看到，第二和第三这两个参数没有什么意思，因为我已经用IND查询出了索引在哪些数据页（fileID:pageID）上面了，下面我们仔细
看看第四个参数。
<1> 0：输出可读形式的数据页页头数据，原因是这样的，在一个数据页中，有96个字节空间来表示一个数据页头，里面的内容可丰富啦。。。。
<2> 1：输出可读形式的数据页页头数据，并且还有槽位对应记录的十六进制内容。
<2> 2：输出整个数据页页头的十六进制数据，包括（页头，内容 和 slot），这个是我最常用的命令。
<3> 3：输出可读形式的数据页页头数据，并且包括记录中每个字段的可读形式。
上面的命令看起来有点玄乎，我就只举一个例子，其他的留给大家试试看啦~~~
DBCC TRACEON(3604) DBCC PAGE(Ctrip,1,110,2)
1 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 2 3 PAGE: (1:110) 4 5 6 BUFFER: 7 8 9 BUF @0x0000000085F8ED00 10 11 bpage = 0x000000008519A000 bhash = 0x0000000000000000 bpageno = (1:110) 12 bdbid = 8 breferences = 0 bUse1 = 8576 13 bstat = 0x3c00009 blog = 0x32159 bnext = 0x0000000000000000 14 15 PAGE HEADER: 16 17 18 Page @0x000000008519A000 19 20 m_pageId = (1:110) m_headerVersion = 1 m_type = 2 21 m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x204 22 m_objId (AllocUnitId.idObj) = 58 m_indexId (AllocUnitId.idInd) = 256 23 Metadata: AllocUnitId = 72057594041729024 24 Metadata: PartitionId = 72057594040877056 Metadata: IndexId = 2 25 Metadata: ObjectId = 245575913 m_prevPage = (0:0) m_nextPage = (1:115) 26 pminlen = 909 m_slotCnt = 8 m_freeCnt = 784 27 m_freeData = 7392 m_reservedCnt = 0 m_lsn = (141:194:170) 28 m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0 29 m_tornBits = -788728362 30 31 Allocation Status 32 33 GAM (1:2) = ALLOCATED SGAM (1:3) = ALLOCATED 34 PFS (1:1) = 0x60 MIXED_EXT ALLOCATED 0_PCT_FULL DIFF (1:6) = CHANGED 35 ML (1:7) = NOT MIN_LOGGED 36 37 DATA: 38 39 40 Memory Dump @0x0000000010CEA000 41 42 0000000010CEA000: 01020000 04020001 00000000 00008d03 †................ 43 0000000010CEA010: 73000000 01000800 3a000000 1003e01c †s.......:....... 44 0000000010CEA020: 6e000000 01000000 8d000000 c2000000 †n............... 45 0000000010CEA030: aa000000 00000000 00000000 d6f5fcd0 †................ 46 0000000010CEA040: 00000000 00000000 00000000 00000000 †................ 47 48 ........... 49 50 0000000010CEBFE0: 21212121 21212121 21212121 21212121 †!!!!!!!!!!!!!!!! 51 0000000010CEBFF0: 5019c015 3012a00e 100b8007 f0036000 †P...0.........`. 52 53 OFFSET TABLE: 54 55 Row - Offset 56 7 (0x7) - 6480 (0x1950) 57 6 (0x6) - 5568 (0x15c0) 58 5 (0x5) - 4656 (0x1230) 59 4 (0x4) - 3744 (0xea0) 60 3 (0x3) - 2832 (0xb10) 61 2 (0x2) - 1920 (0x780) 62 1 (0x1) - 1008 (0x3f0) 63 0 (0x0) - 96 (0x60)
说到聚集索引，我想每个码农都明白，但是也有很多像我这样的猥程序员，只能用死记硬背来解决这个问题，什么表中只能建一个聚集索引，
然后又扯到了目录查找来帮助读者记忆。。。。问题就在这里，我们不是学文科，，，不需要去死记硬背，，，我们需要的就是能看到在眼里面的
真实东西。。。。。我们都喜欢聚集索引，因为它能够把无序的堆表记录变成有序，还玩起了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)数据页就可以啦。。。
当你看到这里的时候，不知道你是否已经明白，为什么表中只能有一个聚集索引呢？？？好了，乱鸡巴扯了好多，希望对你有所帮助。
