我們在學sqlserver的時候，大多教科書和前輩們都說狀態少的欄位不要建索引，由此帶來的開銷還不如不建索引，但是這句話有多少人真的知道，
或者說有多少人真的對此有比較深刻的理解，而不是聽別人道聽途說。。。這樣記得快，忘記的也不慢。。。這篇我來分析一下這句話到底有幾個意思。
一：現象
首先我們還是用測試資料來發現問題，我先建立一個Person，有5個欄位，建表sql如下：
DROP TABLE dbo.Person CREATE TABLE Person(ID INT PRIMARY KEY IDENTITY,NAME VARCHAR(900),Age INT,Email VARCHAR(20),isMan INT ) -- 在isMan欄位建立非聚集索引（0：女 1：男） CREATE INDEX idx_isMan ON dbo.Person(isMan) DECLARE @ch AS INT=0 WHILE @ch<=100000 BEGIN INSERT INTO dbo.Person(NAME,Age,Email,isMan) VALUES ( REPLICATE(CHAR(@ch),50), @ch, CAST(CAST(RAND()*1000000000 AS INT) AS VARCHAR(10))+'qq.com', @ch%2 ) SET @ch=@ch+1 END
通過上面的sql可以發現表中有5個欄位，ID為聚集索引，isMan為非聚集索引，isMan也就是兩種狀態（0,1），並且插入10w條記錄，截圖如下：
sql都做完了，接下來要做的事情就是查詢下： isMan=1的記錄，如下圖：
麻蛋。。。。哥哥明明是在isMan上做資料檢索的，怎麼就變成 “聚集索引掃描”了？？？這他麼的什麼意思嘛，居然不走我的“idx_isMan”索引，
卻走他麼的“聚集索引(PK__Person__3214EC276EF57B66)”。。。。同時也看到上面的”邏輯讀取”為521。。。說明在記憶體中走了521個資料頁。
但是我不服呀。。。我一定要讓執行計劃走我的索引。。。辦法就是強制指定。。。如下圖。
看到上面的圖，你是不是已經瘋了。。。老子才撈5w的資料，你給我走了10w多次資料頁。。。這麼說1條記錄要走兩個資料頁。。。而掃描聚集
索引才走521個資料頁，相差200倍。。。難怪執行計劃打死也不走“idx_isMan”這條索引。。。要是這樣走了人家還不拿刀捅了sqlserver麼？？？
二：分析原因
現在很生氣，整個人都不好了，為什麼會這樣？？？為了找出問題，我們還得看資料頁。
1 DBCC TRACEON(3604,2588) 2 DBCC IND(Ctrip,Person,-1)
通過上面的三個圖，大概可以看到，10w條資料用了697資料頁，其中聚集索引有521個，非聚集索引為176個，這也說明了上面的”聚集索引掃描“走
遍了它自己所有的資料頁來才撈出資料，同時還發現這兩個索引都有一個共同特徵就是，只有一個根節點(indexLevel=1）和無數個（indexLevel=0）
葉子節點，然後我腦子裡面就有一幅圖出來了。。。
上面就是我構思出來的圖，這個專業一點的名字叫做書籤查詢。。。我們通過建立”idx_isMan“索引後，就會構建右半圖的B樹結構，其中索引記錄
會存放兩個值，一個是索引值isMan和一個聚集索引值ID，如果你不相信的話，可以通過DBCC Page去探索"idx_isMan"的索引頁，你也可以通過
DBCC SHOW_STATISTICS 去檢視，如圖：
然後引擎通過“idx_isMan“掃描後，拿到了key值，但是非常可惜，我是select * 的，所以必須還要噴出記錄中的Name，Emai等l欄位，但是
”index_isMan"中並沒有儲存這幾個欄位，所以必須通過key去”聚集索引“的B樹中去找。。。最後通過”聚集索引“的B樹找到了目標記錄，這也
就是所謂的執行計劃中的”鍵查詢“，然後噴出”Name，Email“等欄位。。。。問題就在這裡。。。因為我這樣來回的蹦躂蹦躂。。。造成了找出
完整的一個記錄，需要蹦躂2-3次資料頁。。。具體的尋找記錄，可參考圖中的”紫色線條“，最後也就造成了10w多次蹦躂。。。
三：啟示
那這個例子給我們什麼啟示呢？？？仔細想想你就知道。。。使用非聚集索引，千萬不要撈取過多的資料。。。因為過多的資料會造成在多個
B樹中來回的蹦躂。。。想要做到撈取資料較少，就必須在高唯一性的欄位上建立索引，這樣的話在非聚集索引B樹中符合的資料相對較少，也就
減少了我蹦躂到”主鍵索引“的B樹次數。。。這樣的話來回蹦躂的次數遠遠比”聚集索引“掃描來的實惠，對不對。。。
所以結論出來了：必須在唯一性較高的欄位上建立非聚集索引。