聚集索引在sysindexes内有一行，其indid=1。数据链内的页和页内的行按聚集索引键值排序。所有插入操作都在所插入行中的键值与排序顺序相匹配时执行
对于聚集索引来说，叶子节点就是索引本身，每一个叶子节点所包含的条目其实就是表中的行。对于非聚集索引来说，叶子节点每一个叶子包含的一行就是一个条目。每一个条目由索引键列，可选的包含列以及书签构成，而书签又由聚集索引键或RID构成。
非叶子节点仅仅包含索引键，对于拥有包含列的索引来说，包含列仅仅存在于叶子节点。
指向页的指针包含了文件号和页号。比如说5:4567指向的就是第5个文件的4567个页。
索引深度
索引的根页以及相关信息是存在系统表中的。每当SQL Server进行页查找时，SQL Server都会从根页开始查找，经过中间节点，直到找到叶子节点，然后从叶子中找到需要的索引条目。对于我们10亿行的表来说，从根节点到叶子节点共需要读取5层。而对图1所示的节点来说，只需要读取3次IO。
上面所说的层数，也被成为索引深度。取决于索引键的大小和数量。在AdventureWorks示例数据库中，没有哪个索引的层级超过3层。但对于其它索引键宽或是数据量大的表，就会有更深的层级。
sys.dm_db_index_physical_stats函数可以展示索引的详细信息,深度和大小。这是一个表值函数，比如下面代码我们可以找到SalesOrderDetai表相关的索引信息。
SELECT OBJECT_NAME(P.OBJECT_ID) AS 'Table' ,
I.name AS 'Index' ,
P.index_id AS 'IndexID' ,
P.index_type_desc ,
P.index_depth ,
P.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(),
OBJECT_ID('Sales.SalesOrderDetail'),
NULL, NULL, NULL) P
JOIN
sys.indexes I ON I.OBJECT_ID = P.OBJECT_ID
AND I.index_id = P.index_id ;
通过如下代码我们可以看到更详细的层级信息.
SELECT OBJECT_NAME(P.OBJECT_ID) AS 'Table' ,
I.name AS 'Index' ,
P.index_id AS 'IndexID' ,
P.index_type_desc ,
P.index_level ,
P.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(),
OBJECT_ID('Sales.SalesOrderDetail'), 2,
NULL, 'DETAILED') P
JOIN
sys.indexes I ON I.OBJECT_ID = P.OBJECT_ID
AND I.index_id = P.index_id ;
可以看出
叶子节点的条目分布在407页中
中间节点仅仅需要2页
根节点只有1页
根据索引键的选择，书签的大小的不同，叶子节点通常是非叶子节点大小的上百倍。根据具体的数据不同而不同。
记住包含列仅仅适用在非聚集索引并且只存在于叶子节点中，包含列对于上层的层级是透明的，这也是为什么包含列不会增加非叶子节点键的大小。
因为聚集索引的叶子节点是表数据本身，所以除了叶子节点的数据是表数据本身之外，还需要存储一些额外的非叶子层级。因为无论是否有聚集索引数据本身都是存在的，所以创建聚集索引的时候不仅需要花费一些时间和资源，创建成功后还需要一些额外的空间存储非叶子节点。
树的高度主要和以下几个因素相关
表的总行数。
平均一行保存数据的大小。
页的平均密度。因为不是每一页都应该填充满数据，这样可以减少页拆分的次数。
一页所能容纳的行数。
具体公式也很简单，3级索引大概能容纳4百万行，4级索引大概能容纳4亿行数据。因此通常一张表的索引层数通常为3到4级。
2.3非聚集索引
非聚集索引也是以B树组织的。和聚集索引的区别就在于它的页层并不包含所有的数据。它只包含了键列的数据，并包含了一个行定位符(row locator)。这个行定位符的具体内容取决于它建立在以堆形式的表还是以B树组织的表，换句话说也就是这张表是否建立了聚集索引会影响到非聚集索引的行定位符。如果是建立了聚集索引，那么这个行定位符就是一个聚集键，我们通过这个聚集键再次查找聚集索引上的数据。
如果表是堆组织结构的，那么它就是一个直接指向数据所在行的物理指针。
2.3.1 如果非聚集索引包含了我们需要查找的所有数据
这种情况我们通常叫做索引覆盖。
正因为非聚集索引有着和索引一样的结构，并且由于非聚集索引所包含的列少，因此数据量就小，使得页层的一页能包含更多的行，因此进行一次I/O页读取的动作的时候，就能读取进更多的行。因此查找效率是最高的。
举个不恰当的例子，美女征婚，应征人员的个人信息表有 “姓名、 德、 智、 体 、美、 劳、 高、 富、 帅”这几列，按姓名排序。美女只关注“高、 富、 帅”这三列的内容，为了更快的筛选，我们帮美女按照个人信息表的内容重新制作了一张表，这张表忽略了其他信息，只保留了高、富、帅和姓名，筛选效率当然就比原来关注更多内容时要高。
2.3.2 如果非聚集索引不包含我们需要查找的所有数据
通俗的说这时我们就需要从非聚集索引中所包含的线索去包含所有数据的表中去找。
按照我们之前的定义换句话来说，就是通过非聚集索引中的行定位符去聚集索引或者堆中去查找所需的数据。
在SQL Server中，索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块
一、索引块与数据块的区别
大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用1000字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样IO访问量要少的多。
二、索引优化技术
是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条×1000字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。
三、聚簇索引与非聚簇索引的本质区别
现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。
还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条×1000字节/8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。
同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。
下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外1000个页数据节点才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多
