我是否需要設置一個僅包含幾個可能值的列作爲tSQL的索引？

Question

我創建可能包含數百萬條記錄的SQL Server 2008數據庫，我想知道如果我需要定義以下的指標：

1. TINYINT列可能只包含0和1？

2. TINYINT列可以僅包含：0，5，和6'

PS。這兩列將在WHERE子句中用於選擇。

Answer 1

否，則這些列的索引單獨基本上將永遠不會被使用。

但是，這種低選擇性鍵組合鍵，放置在索引中的最左邊的列作出巨大的候選者。 Eg.say的TINYINT (0,1)（爲什麼不使用bit BTW？）是deleted列。你有頻繁的查詢，用WHERE deleted=0 AND ...來判斷。將這添加爲聚集索引中最左邊的列通常是正確的方法。或者，如果謂詞是WHERE name = '...' AND deleted=0，那麼您應該創建一個非聚類index on (deleted, name)。

另一種選擇是使用filtered index：create index .. on (name) where (deleted=0)但是這並不能掩蓋在那裏你是感興趣的deleted=1的情況。

同樣適用於列數很少的列，例如type列。同樣，將它作爲複合索引中最左邊的鍵通常很有意義。

注意的是，如果你增加一個低選擇性鍵索引中最左邊的鍵，你做不在謂詞指定此列（如WHERE name='...'瓦特/ O添加任何標準deleted），那麼指數不能只能使用索引on (name)（或on (name, ...)），即。其中name是最左邊的鍵。

爲什麼不把它放在最重要的位置？例如。 index on (name, deleted)？因爲通常沒有任何好處，只是如果你想強制執行一個唯一的約束。只有0或1可以選擇index on (name)或index on (name, deleted)基本上可以提供相同的性能（如果可以使用）。將低選擇性鍵放在左側可啓用一些範圍掃描場景（例如，WHERE type=5）。

Answer 2

這不是一個好主意，因爲該指數的選擇性會低，因爲這個，而不是「加快」，它可能是一個缺點。

索引的選擇性是越少越好行具有相同的值

在其他一些情況下甚至全表掃描可能會更有效。

讓的說：你有一個百萬行。然後，第一索引的選擇性是：

（選擇性=不同的值/行）

2/1.000.000 = 0,000002 

在另一種情況下

：

3/1.000.000 = 0,000003 

這些值非常低！

或者對以不同的方式：

估計選擇性比率=（TotalRows /不同的值）/ TotalRows * 100 = 1/Distinc值* 100。

在第一種情況是在50％第二個是33％。

SQL Server的優化器不使用具有這個比例更大然後15％的指標。

（我的計算一個簡單的估算，但你可以找到在MSDN統計信息）