Sql Server查询性能优化之不可小觑的书签查找介绍（2）

书签查找是怎么发生的

和许多人一样看到大神们画的二叉树索引结构图就脑袋大，看得云里雾里，所以这里我们以表Users为例来说聚集索引(PK_UserID)和非聚集索引(IX_UserName)的结构可以简单的表示为下图

首先我们来看聚集索引PK_UserID，对于聚集索引来说数据行就是其叶子节点，故当执行聚集索引查找时找到了具体的键值后就可以直接去叶子节点获取所有需要的数据不需要进行额外的逻辑读，比如select * from Users where UserID=2,根据值2在索引PK_UserID中找到UserID为2的值后去叶子节点就可以拿到所需数据，然后返回查询结果

然后看非聚集索引IX_UserName，上面我们说过非聚集索引覆盖的列为非聚集索引的键列+包含的列+聚集索引的键列,对于IX_UserName来说就是如图中所示键列UserName保存在索引的二叉树节点中，聚集索引的列包含在其叶子节点中，这也就形成了对列(UserName,UserID)的覆盖，对于查询1(select UserID,UserName from Users with(index(IX_UserName)) where UserName='Robert')来说查询只用到了UserName,UserID列，这样只需要扫描索引IX_UserName即可拿到所有数据然后进行结果返回，而对于查询2、查询3来说由于需要用到Age列，而索引IX_UserName中并没有包含Age列，这时就需要个书签查找(bookmark lookup)根据叶节点中的RowID去定位到具体的数据行获取Age列值，对于示例查询来说先根据索引IX_UserName定位Robert所在行，然后根据RowID=3去数据表里获取Age值，然后完成查询，对于查询4来说需要更多的列(Age,Gender,CreateTime)，同样定位到Robert所在行RowID=3，去数据表一次性拿到Age,Gender,CreateTime数据然后返回，这样就形成了书签查找(查询计划中显示为键查找或RID查找)

书签查找的对查询性能的影响
--这是我们现在使用的索引create index IX_UserName on Users(UserName)

打开IO统计并执行下面两个查询 

代码如下:


--set statistics io onselect * from Users where UserName like 'ja％'select * from Users with(index(IX_UserName)) where UserName like 'ja％'



两个查询都返回2条数据，聚集索引扫描仅仅2次逻辑读，使用索引IX_UserName却达到了6次的逻辑读

我们示例的数据量比较小，所以感受不明显，不过我们却也看到了我们在UserName列上市建立了索引 IX_UserName，默认情况下查询优化器并没有使用我们的索引，而是选择了表扫描，仅仅需要2次逻辑读就拿到了我们需要的数据，在我们使用索引提示强制查询优化器使用索引IX_UserName后，同样也是返回2条数据，逻辑读缺达到了惊人的6次，看查询计划使用IX_UserName后发生了书签查找，而这个开销主要是有书签查找造成的，而且随着我们返回数据量的增加，由书签查找导致的逻辑读将会成直线上升，造成的结果就是查询开销比进行全表扫描还要大的多，最终导致索引失效