索引外鍵列

在所有外鍵列上放置索引是否是一條經驗法則？看起來他們經常被用在表連接中，並且會從索引中獲益。索引外鍵列

如果FK列只有2或3個可能值會怎麼樣？例如，如果它正在引用狀態表。將索引放在FK字段上仍然是可取的嗎？

編輯我想重新做這個問題。 [是不是最好把索引列上幾乎沒有可能的值（2或3）？] 編輯完

2011-03-27 Lord Tydus

（兩個問題走到一起的位置：機器效率和DBA的效率。）

作爲一個經驗法則，查詢性能優勢從指標上使用JOIN子句列在WHERE子句。當然，插入，更新和刪除性能也會受到相同索引的影響。（因爲索引必須與表一起更新）

如果某列的值很少，並且有一個令人信服的理由來避免在表中存儲實際值，那麼我更喜歡使用人類可讀的代碼作爲外鍵引用的目標。例如，ISO 5218規定了代表人類性別的這些代碼。

Sex_id Sex 
-- 
0  Not known 
1  Male 
2  Female 
9  Not applicable

我不希望人們記住意味着不適用。如果這是我的全部，那麼我每次需要輸出供人閱讀時都必須加入這張表。

但我可以添加一列到該表中，聲明它是唯一的，並將其用作外鍵引用的目標。大部分時間我都不需要加入這張桌子。哎呀，我可能從來沒有必須加入它。避免加入與機器效率有關。

sex_id sex_code sex 
-- 
0  Un   Not known 
1  M   Male 
2  F   Female 
9  NA   Not applicable

所有這三列應聲明爲唯一。而在大多數平臺上，這意味着這三列中的每一列都會得到一個索引。即使選擇性會很低，我也會對引用sex_code的列進行索引。

爲什麼？我有更好的事情要做，比重新評估是否增加一個索引現在，因爲這個版本的優化器足夠聰明地利用它。這與DBA的效率有關。

來源

2011-03-28 00:18:59

不，它不應該。索引只能在使用時使用。只有當表格尺寸足夠大時，索引纔有用，例如至少有三個塊。對於短行，這可以很容易地爲數百行。

來源

2011-03-27 19:55:48 Eelke

我會強烈反對Eelke - 大多數SQL Server大師將推薦在外鍵列上放置一個非聚集索引，我同意。

有關這些指數的理由和最佳論證的最佳總結，請參閱Kimberly Tripp的優秀博客文章When did SQL Server stop putting indexes on foreign keys? - 答案是：從不 - 它從來沒有這樣做（這是許多持續的城市神話之一 - 但它仍然是一個神話）。

她的核心信息是：

在那裏索引外鍵列什麼好處？ 是在維護上關係

更好的性能，刪除主鍵/唯一鍵的。當您刪除一個關鍵行時，SQL Server必須檢查是否有任何行引用了要刪除的行。
o如果外鍵關係沒有處理定義（在更新/刪除），然後引用行不能被刪除，因爲它會離開引用行「孤立」。要查找的行有效的索引上外鍵列幫助！
o如果外鍵關係與CASCADE定義（上更新/刪除），則當參考行要修改所有的引用行的必須被修改爲以及（或者更新以反映新值或上級聯刪除）。到找到要修改的行，外鍵列有幫助！

更好的連接性能 - 對於許多的上述原因，SQL服務器可以更有效地找到行加入時表的連接主/外鍵關係來。但是，這並不總是「最好的」連接的索引選擇，但它是一個良好的開始。

來源

2011-03-27 20:07:31

回答

相關問題