起因
在執行計劃中看到了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進行緩存，這個有待證實。
