使用外鍵引用小表時是否需要非聚集索引
我不是 DBA，如果這個問題聽起來很愚蠢，請原諒。希望我能從有經驗的DBA那裡得到幫助，因為我一直在質疑這個問題。
假設有2張表，一張表有很多記錄，一張表只是靜態數據，有2條記錄（例如：是/否表）。
以這兩個表為例：
Table_Yes_No（只有 2 條記錄：Yes和No。當然它們有一個遞增的集群 PK）Table_Form（非常大的表，有很多記錄，一列對 PK 有 FKTable_Yes_No）。現在我的問題；是否值得在 FK 上放置一個索引（參考
Table_Form表格Table_Yes_No）？該列將僅包含1或2（但未排序，因為沒有索引）。是否值得索引這樣的 FK？SQLFiddle 中的一個範例：http ://sqlfiddle.com/#!18/51614/3/0
無論如何都會查詢該列，問題是索引是否有助於提高性能。小表是靜態數據，永遠不會改變。大表會被大量查詢，上面也會有很多CRUD。
簡短的回答
不。
長答案
不，添加索引可能會損害性能。
是否使用二級/非聚集索引的重要因素是它的選擇性（以及您嘗試執行的搜尋）。Y/N 有兩個值 - 它的選擇性能力將取決於 Y 與 N 的比例。如果它們被平均分配，並且與聚集索引相關的 Y/N 沒有押韻/原因，它們將不是選擇性的，查詢優化器幾乎總是會忽略該索引。
如果您在較大的表上發出刪除或對該 Y/N 列進行更新，則可能會出現減速。沒有有效的方法來更新二級索引，因為它是按 Y/N 組織的 - 所以唯一的選擇是基本上掃描整個索引以查找要更新/刪除的記錄。根據主表中的行數和聚集索引的大小，這可能是一個問題。
注意事項
如果 Y 或 N 很少，並且您需要快速定位這些記錄，則可以使用過濾索引創建一個非常小的索引，該索引僅包含稀疏填充值的記錄。在這種情況下，這可能是有益的，並且與傳統的非聚集索引相比，佔用空間要小得多。
如果您只是想強制執行 Y/N（或其他一些易於理解的程式碼集），則可以通過檢查約束輕鬆處理，這將比 FK 具有更低的成本。
ADD CONSTRAINT CK_<ColumnName>_Is_YesNo CHECK (<ColumnName> IN ('Y','N'))