的SQL Server創建的一列多個非聚集索引VS在短短的一個指數具有多列

Question

假設我有如下表

• UserID（標識）PK
• UserName - 獨特的非空
• UserEmail - 獨一無二非空

什麼是建議最佳性能？

• 創造UserName和非聚集索引UserEmail分別

OR

• 只是一個既包括列

請你爲什麼一個人是在最好的份額，你的想法其他。

Answer 1

需要考慮的另一個要點是：複合索引（由多列組成）只會在n個最左列被引用時纔會使用（例如，在WHERE條款）

所以，如果你有一個單一的化合物索引

(UserID, UserName, UserEmail) 

那麼這個指數可能在下列情況下使用：

• ，當你獨自尋找UserID（僅使用1最左邊的列 - UserID）
• 當你搜索UserID和UserName（使用最左邊的2列）
• 當您搜索所有三列時

但這種單一的化合物指數將永遠能夠被用於搜索上

• 只是UserName - 這是在索引的第二列，因此該指數不能永遠是
• 只是用UserEmail - 這是該指數第三列，因此該指數不能曾經使用

菊st記住這一點 - 僅僅是因爲列是索引的一部分並不一定意味着只有那一列的搜索纔會被該索引支持並加速！

所以，如果您的使用模式和應用程序真的需要UserName和/或UserEmail單獨搜索（不提供其它搜索值），那麼你必須這些列上創建單獨的指數 - 只是一個單一的化合物中的一個會不是有任何好處。

Answer 2

定義索引的最好方法完全取決於你如何使用表格。僅僅通過查看錶定義就沒有明智的選擇索引的方法。

如果您的代碼使用用戶名搜索您的表或通過用戶名將表與另一個表連接起來，那麼定義該列上的索引將是明智之舉。如果您的代碼使用兩列（用戶名和用戶郵件）與另一個表加入表，那麼爲這兩列定義索引將是明智之舉。由於所有的列都被定義爲唯一的，我不相信這會是這種情況，因此您不需要在該表上使用多個列索引。

使用多列索引時可能會有一些額外的建議：多列索引也用於部分適合索引但具有條件的過濾器。
示例： 如果您在用戶名和用戶郵箱（按給定順序）上定義了雙列索引，則在通過兩列（用戶名和用戶郵箱）進行過濾的搜索中，性能會有所提高。使用該索引，您還將在僅使用用戶名的過濾器中獲得性能提升，因爲這是索引的第一列，但不在通過用戶郵件進行的搜索中，這是因爲索引的第二列不能單獨使用。
規則是：索引可用於使用完全匹配的列進行過濾或使用與索引定義中後續頂部列匹配的列子集進行過濾。

Answer 3

請分享你的想法，爲什麼比其他更可取。

這取決於你做什麼。

請參閱索引僅用於「從左到右」。所以，一個用戶ID的indes;如果我選擇僅由用戶名篩選，UserName是無用的。

一般來說，我會假設這裏三個指標：

• Uniuqe指數，在用戶名集羣，作爲主鍵。
• UserName上的唯一索引，非羣集。
• UserEMail上的唯一索引，非羣集。

的原因是完全不適合的性能，但是：

• ，您將需要第一個爲forein鍵關係的主鍵。
• 您需要其他兩個來正確處理唯一約束 - 沒有索引就沒有辦法做到這一點。

此外，您需要靈活性來查找用戶名和用戶電子郵件，這意味着它是不可能的只有它們合併。

性能真的進入了最後 - 因爲性能原因所有這些索引可能包含所有附加字段（不是作爲索引的一部分，而是作爲包含的列）但實際上，沒有其他明智的方式來使此表工作，除非