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

使用覆盖索引避免书签查找

覆盖索引是指非聚集索引上的列(键列+包含列) + 聚集索引的键列包含了查询中用到的所有列，对于索引IX_UserName来说索引覆盖列就是(UserName,UserID)。若查询中只用到了索引所覆盖的列，那么只需扫描索引即可完成查询，若用到了索引覆盖范围以外的列就需要书签查找来获取数据，当这种查找发生次较多时就会导致索引失效从而导致表扫描，因为查询优化器是基于开销的优化器，当其发现使用非聚集索引引发的书签查找开销比表扫描开销还大时就会放弃使用索引，转向表扫描。

1.在UserName,Age列上重建索引IX_UserName，这时对于索引IX_UserName来说覆盖列变为(UserName,Age,UserID)，再次执行上面的查询SQL可以发现查询计划已经发生变化 

代码如下:


drop index IX_UserName on Userscreate index IX_UserName on Users(UserName,Age)

我们可以看到查询2、查询3的书签查找已经消失，因为索引IX_UserName包含了查询中用到得所有列(UserID,UserName,Age)，查询4因为选择返回所有列我们的索引没有包含Gender和CreateTime列，故还是会进行书签查找

这时索引IX_UserName结构表示如下

可见对于查询2、查询3仅仅通过索引IX_UserName既可以拿到需要的列UserName,Age,UserID，而对于查询4索引并没有全部覆盖还是需要进行书签查找

2.继续修改我们的索引IX_UserName，使用include包含非键列(键列就是索引上的列，非键列就是索引之外的列，对于include来说就是存放于非聚集索引叶子节点上的列,聚集索引的列也放在非聚集索引的叶子节点上) 

代码如下:


drop index IX_UserName on Userscreate index IX_UserName on Users(UserName,Age) include(Gender,CreateTime)

可以看到我们修改索引使用include包含了Gender,CreateTime后，索引IX_UserName达到了对数据表Users的所有列的全覆盖,这时候毫无疑问的查询2、查询3没有出现书签查找，查询4的书签查找也消失了。

此时索引IX_UserName 结构如下

索引IX_UserName已经达到了对Users表的全覆盖，对于我们的查询2、查询3、查询4来说，仅通过索引IX_UserName即可完成查询，不需要进行书签查找。

这时我们再来看一下这两个查询的开销及查询计划，可以看到不需要我们进行索引提示，查询优化器已经自动选择了我们的索引，逻辑读也降至了2次

select * from Users where UserName like 'ja％'select * from Users with(index(IX_UserName)) where UserName like 'ja％'

关于Include请参考 SQL Server 索引中include的魅力（具有包含性列的索引）

　　这里说明下书签查找对查询性能有着较大的影响并且基本上不可避免，这并不意味着书签查找就是洪水猛兽，原来我们不是也不知道啥叫书签查找么，查询性能一样也不差，是吧，呵呵。书签查找也说明了为什么我们不推荐写sql时使用select *，也解释了为什么有时候我们的索引会失效，同时可以作为优化查询性能考虑的一个方面，在设计表和索引时尽量规避书签查找带来的负面影响，比如非聚集索引尽量选择高选择性的列即返回尽量少的行，需要大批量数据查询时尽量使用聚集索引等。　　

　　本文中为了便于演示仅仅使用了有几条数据的表，而且查询中为了使用索引都用了索引提示，实际开发中请不要使用索引提示，查询优化器大多数情况下会为我们生成最优(最优不代表开销最小，只要开销足够小即认为最优)的执行计划，索引结构里面用到得RowID也仅仅是为了演示虚构出来的，我们只要认为它是对于数据行的一个标识位就行了。

　　此文旨在让我们认识书签查找并意识到书签查找的意义，从而对于索引失效原因有清晰的认识，更好的理解查询计划。