起因

　　在执行计划中看到了Bookmark Lookup操作符，于是就上网去逛逛，最后发现这篇牛文；

　　主要内容摘要

　　非聚集索引有一个与聚集索引中相似的B树索引结构，但是他对数据行的顺序不起作用，其最低行包含非聚集索引的键值，每个键值项都有指针指向包含该键值的数据行。对于堆集，该指针是指向行的指针，对于聚集表，则是聚集索引键。该指针叫做行定位器；

　　在基于非聚集索引查找数据时，还有另外一种情形，那就是如果放回的数据列就包含于索引的键值中，或者包含于索引的键值+聚集索引的键值中，那么就不会发生 Bookup Lookup，因为找到索引项，就已经找到所需的数据了，没有必要再到数据行去找了。这种情况，叫做索引覆盖；

　　SQL Server在查找数据时，服务器先使用和使用聚集索引相同的查找方法找到该索引的行定位器------Bookmark，然后通过行定位器来找到所需要的数据，这种通过行定位器查找数据的方式就是Bookmark Lookup；

　　查询性能比较：

　　返回行数较多：索引覆盖>聚集索引>表扫描>堆集的非聚集索引>聚集的非聚集索引

　　返回行数较少：索引覆盖=聚集索引>堆集的非聚集索引>聚集的非聚集索引>表扫描

　　一个堆集在sysindexes内有一行，其indid=0；

　　某个表和视图的聚集索引在sysindexes内有一行，其indid=1，root列指向聚集索引B树的顶端；

　　某个表或视图的非聚集索引在索引在sysindexes内也有一行，其indid值从2到250，root列指向非聚集索引B树的顶端；

　　SQL Server 的数据文件中有一类是IAM，即索引分配映射表，它存储有关表和索引所使用的扩展盘区信息；

　　Bookmark Lookup逻辑运算符和物理运算符使用书签（行 ID 或聚集键）在表或聚集索引内查找相应的行；

　　感想

　　里面的"在一个聚集表上使用非聚集索引进行查询，其性能低于在堆集上使用非聚集索引进行查询"（这句话不是完全正确的，因为当返回的字段包含了非聚集索引和聚集索引的列值，那么就会产生索引覆盖，而堆集上使用非聚集索引的返回字段只能是只身才会形成索引覆盖）

　　第一次看这篇文章的时候感觉是在看天书，完全不懂；随着知识的积累，偶尔回来几次看这篇文章，感觉一步步的理解了一点点内容，看来这篇文章还得继续看多几遍啊。！

　　【写有效率的SQL查询（V）】:http://www.cnblogs.com/cn_wpf/archive/2007/08/20/863022.html

　　起因

　　一个使用Ibatisnet框架的系统中，使用map来访问数据库（sql2000），如果字段是变长，那就要会导致无法使用计划缓存，其实就是 sp_executesql来执行存储过程，使得无法使用计划缓存，虽然最后通过新增存储过程来解决这个问题，但是一直没有得到理论上的证实，所以上网以"sp_executesql"为关键字搜索了，最后找到这篇文章；

　　主要内容摘要

　　直接拼SQL

　　参数化SQL

　　调用存储过程

　　这里不得不提.NET SqlClient组件的一个龌龊：如果你的参数中包含varchar或者char类型的参数，你在Parameters.Add的时候又没有指定长度，它都会根据你实际传入的字符串长度(假设是n)给你重新定义成nvarchar（n） 。如：select * from mytable where col1 = @p1，你设置@p1为'123456'，实际传到sql这边的命令是：exec sp_executesql N'select * from mytable where col1 = @p1',N'@p1 nvarchar(6)',@p1=N'123456'。这样，系统缓存中实际存储的sql是：(@p1 nvarchar(6))select * from mytable where col1 = @p1。看到了吧？如果你的输入参数变动比较多，那么看起来同样的一条语句，会被编译很多次，在缓存中存储很多份。cpu和内存都浪费了。这也是在《写有效率的SQL查询IV》中建议的使用最强类型参数匹配的原因之一。

　　感想

　　通过自己的知识和实践得到了某些东西，后来又等到理论证实，这种感觉真的很棒、很爽（主要是发现和解决问题的能力）；

　　虽然这是一个比较简单的问题，或者其它人也很容易的发现并解决这个问题，但是能有这么一件开心的事，我们还需要求什么呢？！

　　感觉它描述的比我好，主要还有例子作为解说；

　　听说SQL Server2005可以对adhoc进行缓存，这个有待证实。