在我們講解這個案例前，我們先來了解/預熱一下SQL Server的兩個概念：鍵查找（key lookup)和RID查找（RID lookup),通常，當查詢優(yōu)化器使用非聚集索引進行查找時，如果所選擇的列或查詢條件中的列只部分包含在使用的非聚集索引和聚集索引中時，就需要一個查找（lookup）來檢索其他字段來滿足請求。對一個有聚簇索引的表來說是一個鍵查找（key lookup），對一個堆表來說是一個RID查找（RID lookup），這種查找即是——書簽查找(bookmark lookup)。在其他數(shù)據(jù)庫概念中，可能又叫回表查詢之類的概念。

那么我們先來構(gòu)造案例所需的測試環(huán)境。下面測試環(huán)境為SQL Server 2014。

SELECT * INTO TEST FROM SYS.OBJECTS
CREATE CLUSTERED INDEX PK_TEST ON TEST(OBJECT_ID, NAME,CREATE_DATE)
CREATE INDEX IX_TEST_N1 ON TEST(PARENT_OBJECT_ID, TYPE)
UPDATE STATISTICS TEST WITH FULLSCAN;

如上所示，表TEST在字段OBJECT_ID, NAME,CREATE_DATE建立了聚集索引，然后下面這種查詢語句，你查看其實際執(zhí)行計劃

SELECT OBJECT_ID, NAME,CREATE_DATE,PARENT_OBJECT_ID, TYPE 
FROM TEST WHERE PARENT_OBJECT_ID=2255213;

你會發(fā)現(xiàn)，SQL Server優(yōu)化器走索引IX_TEST_N1查找就返回了所有數(shù)據(jù)。沒有書簽查找（回表查詢），那么這是為什么呢？朋友這樣問我的時候，我還真沒有想明白。難道索引IX_TEST_N1中也會存儲OBJECT_ID, NAME,CREATE_DATE的值？ 當然你構(gòu)造其它的案例時，有可能是索引IX_TEST_N1掃描就返回了數(shù)據(jù)。不會發(fā)生書簽查找。

后面才想明白，非聚集索引中的索引行指向數(shù)據(jù)行的指針稱為行定位器。 行定位器的結(jié)構(gòu)取決于數(shù)據(jù)頁是存儲在堆中還是聚集表中。 對于堆，行定位器是指向行的指針。 對于聚集表，行定位器是聚集索引鍵。這是不是有點眼熟，類似于MySQL InnoDB的二級索引（Secondary Index）會自動補齊主鍵，將主鍵列追加到二級索引列后面。所以執(zhí)行計劃就走索引IX_TEST_N1查找就能返回數(shù)據(jù)了。根本不需要書簽查找（回表查詢）。如果查詢語句多一個字段或者是SELECT *的話，你就會看到書簽查找了。如下所示

到此這篇關(guān)于SQL Server索引查找/掃描沒有出現(xiàn)key lookup的案例淺析的文章就介紹到這了,更多相關(guān)SQL Server索引查找/掃描內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論