列作為包含列或鍵列
我有一個查詢，它在 column 上有一個可選的 where 條件
classID(not unique)。這同樣classID被顯示為各種其他查詢中的選擇列。目前我將 classID 作為索引中的包含列idx，所以我認為當 classID 在 select 語句中時將使用 idx。當查詢具有 classID 的 where 條件時，我是否必須為 classID 創建一個非聚集索引作為鍵列？對此是否為所有 where 子句列單獨創建感到困惑
non-clustered indexes。？
目前我將classID作為索引idx中的包含列，所以我認為當classID在select語句中時將使用idx。
不，不是。在查詢計劃中選擇的索引取決於查詢優化器決定哪個索引最能滿足查詢要求。如果您的索引鍵列與您的查詢謂詞匹配或非常相似，那麼它可能會選擇該索引。
在 INCLUDE 列中包含 ClassID 僅意味著查詢計劃不需要鍵查找來檢索有關查詢中返回的行的附加數據。如果 ClassID 是謂詞，則將其放在索引的 INCLUDE 列中不會導致優化器明確選擇該索引。
當查詢具有 classID 的 where 條件時，我是否必須為 classID 創建一個非聚集索引作為鍵列？
您需要創建最能滿足最常見數據訪問的索引。例如，如果您創建了一堆具有單個鍵列和許多包含列的索引，但您的查詢有很多謂詞和很少的選擇列，那麼您的索引策略不太可能達到應有的效率。
當您開始使用索引調整\設計時，一個好的起點/經驗法則是每個表不超過 5 個索引，每個索引不超過 5 列。這有助於您對創建的索引以及如何設計它們來滿足大多數查詢更有選擇性。
這不是一個硬性規定，它只是幫助您考慮與查詢相關的索引策略。
對是否為所有 where 子句列創建單獨的非聚集索引感到困惑。？
您不會為每個謂詞創建單獨的索引，因為優化器可能只使用其中一個，然後執行一堆鍵查找。使用以下基本準則設計索引：
- 查詢中的 WHERE 子句和 JOIN 列應該是索引中的關鍵列。
- 查詢中的 SELECT 列應包含索引中的列。
這些不是硬性規定，並且再次不要設計索引來滿足單個查詢。您需要分析您的數據訪問特徵並製定索引策略，以使用最少的索引滿足最多的查詢，從而獲得最大的效率。
一些不錯的資源：