Sql Server中的非集合索引具體介。本站提示廣大學習愛好者：（Sql Server中的非集合索引具體介）文章只能為提供參考，不一定能成為您想要的結果。以下是Sql Server中的非集合索引具體介正文
非集合索引，這個是年夜家都異常熟習的一個器械，有時刻我們因為營業緣由，sql寫的異常龐雜，須要join許多張表，然後就泣如雨下了。。。這時候候就有DBA或許資深的開辟給你看這個鄙陋的sql，經由過程履行籌劃一剖析。。。也許就看出了不應有的表掃描。。。萬惡之源。。。然後給你在症結的字段加上非集合索引後。。。才發明提速比阿斯頓馬丁還要快。。。那末一個成績來了，為何非集合索引能提速這麼快。。。怎樣做到的？？？是否是異常的獵奇？？？
這篇我們來解開奧秘面紗。
一：景象
先讓我們一睹非集合索引的真容，看看究竟在履行籌劃看來是個甚麼玩意。。。我這裡有個product表，外面灌了8w多半據，然後在Name列上樹立
一個非集合索引，就像下圖一樣：
從上圖中看到了兩個好玩的器械，一個就是我想看到的“索引查找[nonclustered]”，這個年夜家很熟習，也是這篇要說的，然後我們還看到了一個“RID查找”，乍一看這是甚麼雞巴玩意。。。非集合索引跟它扯上甚麼關系了？？？
二：甚麼是RID
經由過程後面幾篇，我想年夜家都曉得了數據頁中的記載是若何尋覓的？機密就是經由過程slot槽位中的偏移量決議的，那成績來了，假如上升到數據頁層面，我只須要（pageID：slotID）便可以找到記載了，對纰謬？那假如我上升了文件層面，那是否是只須要曉得（fileID:pageID:slotID)便可以找到數據頁中的 記載了？其實這裡的RID就是站在文件的高度經由過程(fileID:pageID:slotID)找到表記載的。。。既RID=RowID=(fileID:pageID:slotID)，假如你非要目擊實的話，在sq中l還真供給了這麼個函數（sys.fn_PhysLocFormatter(%%physloc%%)），我們看下圖：
看了下面的圖，是否是很高興，了如指掌，好比productID=18088這筆記錄，然來是在1號文件，34941號數據頁，0號槽位上，productID=18089是在1號槽位上，好了，當你曉得RID是個甚麼器械的時刻，我想你曾經離完全懂得非集合索引不遠啦。。。
三：非集合索引
有一點我們確定曉得，就長短集合索引是可以加快查找的，如果跟表掃描那樣的龜速，那也就掉去了索引的目標，既然能加快，是由於它和集合索引一樣，在底層都玩起了B樹，起首我們拔出一些樣例數據。
DROP TABLE dbo.Person CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(900)) CREATE INDEX idx_Person_Name ON dbo.Person(Name) DECLARE @ch AS INT=97 WHILE @ch<=122 BEGIN INSERT INTO dbo.Person VALUES(REPLICATE(CHAR(@ch),5)) SET @ch=@ch+1 END
下面的sql，我有意在Name列設置為900個char，這也是索引的下限值，如許的話，我DBCC便可以導出許多數據頁和索引頁了。
可以看到，當我dbcc ind 的時刻，發明Person表中曾經有4個數據頁，5個索引頁，個中151號數據頁是表跟蹤頁，174號為索引跟蹤頁，這也就解釋當我樹立索引後，引擎給我們分派了專門的索引頁來寄存我們樹立的Name索引，那下一步就是我們來看看這些索引中都寄存著甚麼，這也是我異常關懷的，接上去我導出173號索引頁。
DBCC PAGE(Ctrip,1,173,1)
Slot 0, Offset 0x60, Length 912, DumpStyle BYTE Record Type = INDEX_RECORD Record Attributes = NULL_BITMAP Record Size = 912 Memory Dump @0x000000000EF1C060 0000000000000000: 16616161 61612020 20202020 20202020 †.aaaaa 0000000000000010: 20202020 20202020 20202020 20202020 † 0000000000000020: 20202020 20202020 20202020 20202020 † 0000000000000030: 20202020 20202020 20202020 20202020 † 0000000000000040: 20202020 20202020 20202020 20202020 † 0000000000000050: 20202020 20202020 20202020 20202020 † 0000000000000060: 20202020 20202020 20202020 20202020 † 0000000000000070: 20202020 20202020 20202020 20202020 † 0000000000000080: 20202020 20202020 20202020 20202020 † 0000000000000090: 20202020 20202020 20202020 20202020 † 00000000000000A0: 20202020 20202020 20202020 20202020 † 00000000000000B0: 20202020 20202020 20202020 20202020 † 00000000000000C0: 20202020 20202020 20202020 20202020 † 00000000000000D0: 20202020 20202020 20202020 20202020 † 00000000000000E0: 20202020 20202020 20202020 20202020 † 00000000000000F0: 20202020 20202020 20202020 20202020 † 0000000000000100: 20202020 20202020 20202020 20202020 † 0000000000000110: 20202020 20202020 20202020 20202020 † 0000000000000120: 20202020 20202020 20202020 20202020 † 0000000000000130: 20202020 20202020 20202020 20202020 † 0000000000000140: 20202020 20202020 20202020 20202020 † 0000000000000150: 20202020 20202020 20202020 20202020 † 0000000000000160: 20202020 20202020 20202020 20202020 † 0000000000000170: 20202020 20202020 20202020 20202020 † 0000000000000180: 20202020 20202020 20202020 20202020 † 0000000000000190: 20202020 20202020 20202020 20202020 † 00000000000001A0: 20202020 20202020 20202020 20202020 † 00000000000001B0: 20202020 20202020 20202020 20202020 † 00000000000001C0: 20202020 20202020 20202020 20202020 † 00000000000001D0: 20202020 20202020 20202020 20202020 † 00000000000001E0: 20202020 20202020 20202020 20202020 † 00000000000001F0: 20202020 20202020 20202020 20202020 † 0000000000000200: 20202020 20202020 20202020 20202020 † 0000000000000210: 20202020 20202020 20202020 20202020 † 0000000000000220: 20202020 20202020 20202020 20202020 † 0000000000000230: 20202020 20202020 20202020 20202020 † 0000000000000240: 20202020 20202020 20202020 20202020 † 0000000000000250: 20202020 20202020 20202020 20202020 † 0000000000000260: 20202020 20202020 20202020 20202020 † 0000000000000270: 20202020 20202020 20202020 20202020 † 0000000000000280: 20202020 20202020 20202020 20202020 † 0000000000000290: 20202020 20202020 20202020 20202020 † 00000000000002A0: 20202020 20202020 20202020 20202020 † 00000000000002B0: 20202020 20202020 20202020 20202020 † 00000000000002C0: 20202020 20202020 20202020 20202020 † 00000000000002D0: 20202020 20202020 20202020 20202020 † 00000000000002E0: 20202020 20202020 20202020 20202020 † 00000000000002F0: 20202020 20202020 20202020 20202020 † 0000000000000300: 20202020 20202020 20202020 20202020 † 0000000000000310: 20202020 20202020 20202020 20202020 † 0000000000000320: 20202020 20202020 20202020 20202020 † 0000000000000330: 20202020 20202020 20202020 20202020 † 0000000000000340: 20202020 20202020 20202020 20202020 † 0000000000000350: 20202020 20202020 20202020 20202020 † 0000000000000360: 20202020 20202020 20202020 20202020 † 0000000000000370: 20202020 20202020 20202020 20202020 † 0000000000000380: 20202020 20940000 00010000 00020000 † ...........
Row - Offset
7 (0x7) - 6480 (0x1950)
6 (0x6) - 5568 (0x15c0)
5 (0x5) - 4656 (0x1230)
4 (0x4) - 3744 (0xea0)
3 (0x3) - 2832 (0xb10)
2 (0x2) - 1920 (0x780)
1 (0x1) - 1008 (0x3f0)
0 (0x0) - 96 (0x60)
從下面至多可以發明三個風趣的景象：
<1>:173號索引頁中slot0和slot1槽位指向記載的內容曾經有序了，好比：aaaaa，bbbbb。。。。如許。。。。本來非集合索引也是有序呀。。。
<2>:6161616161就是16進制的aaaaa。
9400000001000000 ：這幾個數字異常主要，由於是16進制表現，所以2位16進制表現一個字節，所以可以這麼說明，後面4個字節表現
pageID，中央2個字節表現fileID，前面2個字節表現slot，看到這裡你是否是想起了RID。。。由於RID就是這三樣的組合。。。本來非集合索
引的記載寄存的就是“key+RowID”呀。。。。
<3>:經由過程最初的槽位列表，可以得知173號索引頁上寄存著8條索引記載。
好了，看完了葉子節點，我們再看分支節點，也就是IndexLevel=1的那條索引數據頁，也就是78號。ok，dbcc看看吧。
當看到這個列表的時刻，不曉得你頭腦外面是否是有一幅圖出來了，就像上一篇看到集合索引一樣，由於它的構造和集合索引異常像，只不外非集合索引這裡多了一個RID罷了。。。最初我也把圖進獻一下。
總結一下：在走非集合索引的時刻，好比你的前提是where name='jjjjj' 時，它的邏輯是如許的，依據78號索引數據頁的key的規模，然後經由過程rowid走到了79號索引數據頁，然後在79號索引數據頁中順遂的找到了jjjjj，這時候候便可以拿出jjjjj的rowid去表數據頁中直接定位記載，最初輸入。。。。。這個也就是博客開首的處所為何會湧現RID的查找。。。
