15
我有一個表用戶與一堆索引。其中之一是AccountIdentifier列上的唯一索引。這個sql查詢爲什麼要做鍵查找？
由於這是一個唯一的索引，爲什麼除索引查找外還需要查找關鍵字？索引查找工具提示報告只返回一條記錄。我也嘗試將索引轉換爲「唯一鍵」類型。
alt text http://s3.amazonaws.com/brandonc.baconfile.com/pitchurs/tmp/capture_2.png
A
回答
17
因爲它是選擇*。
它使用非聚集索引來定位行，但是需要去獲取要返回的數據。
爲了避免bookmark lookup你需要讓非聚集索引覆蓋索引（最好通過減少在選擇列表中，但可能列數也通過添加新的列到索引本身或作爲included columns）
如果表上有聚簇索引，則非聚簇索引中的行定位符將包含聚簇索引鍵，因此無需書籤查找即可滿足AccountIdentifier和聚簇索引列上的查詢。
+1
我做了一些試驗。所以它似乎選擇了不在索引使用結果中的任何關鍵查找。這就說得通了。 – 2010-07-03 00:29:22
+1
@BC - 基本上是的，但如果你有一個聚集索引，你可以考慮自動包含這些列。 – 2010-07-03 00:33:32
13
密鑰查找並不意味着「查找密鑰」，而是「查找基於密鑰的行」。
7
請參閱以下文章和博客上的鍵查找/書籤查找一些背景資料：
相關問題
- 1. 這個SQL查詢做了什麼？
- 2. 這個SQL查詢會做什麼？
- 3. 爲什麼這個SQL查詢很慢？
- 4. 爲什麼這個SQL查詢失敗？
- 5. 這個SQL查詢爲什麼錯了？
- 6. 我爲SQL Server的這個子查詢做了什麼錯誤？
- 7. 這個LINQ查詢做了什麼？
- 8. 這個ORM kohana3查詢做了什麼？
- 9. 爲什麼這個SQL查詢需要DISTINCT？
- 10. 這個查詢應該做什麼？ （爲什麼它會失敗？）
- 11. 這是什麼SQL查詢？
- 12. 這是什麼SQL查詢？
- 13. 查詢優化。 TOAD爲什麼要這樣做？
- 14. 爲什麼這個查詢需要這麼長時間？
- 15. 爲什麼這個查詢需要這麼長時間？
- 16. 爲什麼這個EF查詢需要這麼長時間？
- 17. SQL爲什麼sp比查詢要慢
- 18. 這個SQL查詢有什麼問題？
- 19. 這個SQL查詢有什麼問題？
- 20. 這個SQL查詢有什麼問題？
- 21. 這個SQL查詢有什麼問題？
- 22. 這個sql查詢有什麼問題？
- 23. 這個SQL查詢有什麼問題？
- 24. 這個SQL查詢有什麼問題
- 25. 這個sql查詢有什麼問題？
- 26. 這個SQL查詢有什麼問題？
- 27. 這個SQL查詢有什麼問題？
- 28. 這個SQL查詢有什麼問題
- 29. 這個SQL查詢有什麼問題？
- 30. 這個sql查詢有什麼問題？
順便說一句：永遠不要在生產系統上做SELECT * - **絕不** - 沒有例外。這是不好的做法，開始...... – 2010-07-03 07:03:37