在SQL Server中使用外鍵有嚴重的性能下降嗎？

我正在盡我所能說服我的老闆讓我們在我們的數據庫中使用外鍵 - 迄今沒有運氣。在SQL Server中使用外鍵有嚴重的性能下降嗎？

他聲稱這需要大量的性能，並表示我們現在只需要清理無效的參考資料。

很明顯，這在實際中並不奏效，數據庫中充斥着無效的引用。

有誰知道比較，基準或類似的證明沒有顯着的性能影響使用外鍵？（我希望能說服他）

2010-02-23 Steffen

只是整個故事的更新：現在我們被允許使用外鍵，如果它們可能被禁用，如果它們導致性能損失的概念。所以，非常感謝大家的好評:-) – Steffen 2010-02-25 06:54:57

由於必須檢查FK，因此插入，更新和刪除的性能很小。對於一個單獨的記錄來說，這通常會非常輕微以至於不明顯，除非你開始有一個與桌子相關的可笑數量的FK（顯然，檢查100個其他桌子比2要花費更長的時間）。由於沒有完整性的數據庫是不可靠的，因此毫無用處，這是件好事。你不應該爲了速度而誠實交易。這種性能影響通常被更好的優化執行計劃的能力所抵消。

我們有一箇中等大小的數據庫，其中包含大約900萬條記錄和FK，並且很少注意到性能問題（除非一個設計錯誤的表有100多個外鍵，但刪除記錄有點慢從這一切都必須檢查）。幾乎每個dba，我知道誰處理大型TB級數據庫，並且真正需要在大型數據集上獲得高性能，因爲完整性是任何數據庫的關鍵，所以堅持外鍵約束。如果擁有太字節大小的數據庫的人能夠承受非常小的性能影響，那麼你也可以。

FK不會自動編入索引，如果它們未編入索引，則會導致性能問題。

說實話，我會拿你的數據庫的副本，添加適當索引的FKs，並顯示插入，刪除，更新和從這些表中選擇的時間差，與沒有FK的數據庫中的相同。表明你不會造成性能下降。然後顯示顯示孤立記錄的查詢結果，這些記錄不再具有含義，因爲它們相關的PK不再存在。對於包含財務信息的表格顯示這一點特別有效（「我們有2700個訂單，我們無法與客戶聯繫」將使管理層坐起來並留意）。

來源

2010-02-23 22:46:31 HLGEM

非常有用的信息。我目前正在將外鍵添加到數據庫的副本中，但這需要一些時間，因爲我必須先刪除像2000萬到3000萬無效行。這僅僅證明首先缺少密鑰的問題有多大。 – Steffen 2010-02-24 10:07:33

「你不應該爲了速度交易完整性」 - 但這是大多數NoSql數據庫所做的事情......在某些情況下，這可能是值得的折衷，但在進行此調用之前，應該認真衡量實際效果。 – noocyte 2017-11-22 07:19:10

@noocyte，這就是爲什麼NoSql數據庫通常不適用於任何嚴肅的商業應用程序，尤其是在金融和醫療保健等受監管行業。 – HLGEM 2017-11-22 16:07:31

從Microsoft Patterns and Practices: Chapter 14 Improving SQL Server Performance：

當主鍵和外鍵定義爲數據庫架構限制，服務器可以使用該信息，創造最優執行計劃。

來源

2010-02-23 10:47:31

當然，它可以使用這些索引來優化......但這並不意味着對性能沒有負面影響。我認爲涉及太多的因素使這個問題睡在這個參考文獻中。 – 2010-02-23 10:56:52

@羅蘭：我明白你的意思了，我同意你的意見。但是我的意圖是解決「我盡力說服我的老闆」這個問題的一部分。 – 2010-02-23 10:58:16

@Roland：另外，性能受到的影響非常罕見。正如你在答案中所說的那樣，在不知道應用程序的情況下很難聲稱，但實際上，外鍵的好處很少用於性能交易。相關SO帖子：http：// stackoverflow。com/questions/1744878/can-foreign-keys-hurt-query-performance/ – 2010-02-23 11:16:08

可以關注性能，但是讓偏執決定不是。

你可以很容易地編寫基準代碼來自己展示結果，但首先你需要找出你的老闆關心的是什麼樣的表現，並且準確地說明這些指標。就無效引用ar而言，如果你不允許你的外鍵有空值，你將不會得到無效的引用。如果您嘗試分配一個不存在的無效外鍵，數據庫將會被感知。如果你需要「空值」，分配一個鍵爲「UNDEFINED」或類似的東西，並將其設爲默認鍵。

最後，向你的老闆解釋數據庫正常化問題，因爲我認爲你很快就會發現這個問題比以往的外鍵性能會更爲棘手。

來源

2010-02-23 10:50:28 BenB

我很確定這不是他擔心的任何確切的表現指標，因爲他只是表示「它傷害了表現」，而這就是它。顯然這並不容易證明是錯誤的:-( – Steffen 2010-02-23 11:48:03

如果有人需要「空」，他可以有空列，它不會在FKs上產生問題，我發現添加「自定義」「空行」在主表中爲了不在外表中添加一個可爲空的列比根本不使用FK更差 – 2014-10-09 21:48:17

如果你沒有FK，那麼不允許FK列中的空值不會阻止你進入無效的，如果原始PK記錄被刪除或改變，記錄不會被孤立 – HLGEM 2017-07-03 13:50:55

有誰知道比較，基準或類似的證明沒有顯着的性能影響使用外鍵？（我希望能說服他）

我認爲你會以錯誤的方式去做。基準從未說服任何人。

你應該怎麼做，首先會發現不使用外鍵約束導致的問題。嘗試量化「清理無效引用」需要花費多少工作量。另外，請嘗試並衡量由於這些錯誤而導致業務流程出現多少錯誤。如果你可以附加一美元金額 - 甚至更好。

現在要進行基準測試 - 您應該嘗試深入瞭解您的工作負載，確定哪種類型的操作最經常進行。然後建立一個測試環境，並用外鍵重放這些操作。然後比較。

就我個人而言，如果沒有關於數據庫上運行的應用程序的知識，我不會立即聲明外鍵不會降低性能。特別是如果您將級聯刪除和/或更新與複合自然主鍵結合使用，那麼我個人會擔心性能問題，特別是由於級聯操作的副作用導致的超時或死鎖事務。

但是沒有人能告訴你 - 你必須測試自己，包括你的數據，工作量，併發用戶數量，硬件和應用程序。

來源

2010-02-23 10:51:34

關於應用程序的好處，但表格非常簡單 - 所有主鍵都是標識整數，我們有沒有級聯刪除/更新所以基本上它是如此簡單：-D – Steffen 2010-02-23 11:40:42

Steffen，這是有用的信息。我可能沒有任何保留，除非處理大量的寫入負載。 – 2010-02-23 11:52:04

我相信我們的閱讀方式比寫作更多，所以這也不是什麼大問題。感謝您的評論:-) – Steffen 2010-02-23 12:52:54

成本的一個重要因素是外鍵引用的索引大小 - 如果它很小並且經常使用，性能影響將可以忽略不計，較大和較少使用的索引會產生更大的影響，但是如果您的外鍵反對聚集索引，它仍然不應該是一個巨大的打擊，但@Ronald布曼是正確的 - 你需要測試以確保。

來源

2010-02-23 22:29:40

這是一個政治問題，而不是技術問題。如果您的項目管理人員在維護數據完整性方面看不到任何價值，您需要參與不同的項目。

如果你的老闆還不知道或關心你有成千上萬的無效參考資料，他不會因爲你告訴他而開始關心它。我同情這裏的其他海報，他們試圖通過與好鬥作鬥爭來做到「正確的事情」，但之前我已經嘗試了很多次，在實際操作中它不起作用。大衛和歌利亞的故事使人很好的閱讀，但在現實生活中，這是一個失敗的主張。

來源

2010-10-20 14:36:26

我同意@Dave在這裏，但我鼓勵你繼續打好反抗。不幸的是，有時管理層擔心他們（顯然，雖然我們輕聲說）不理解。這不僅使公司花費美元花費時間來糾正首先不需要發生的問題，而且阻礙了那些實際上最擅長設計這些解決方案的人的創造力和動態解決方案。我保留「永不言敗」的態度，直到給出或證實了堅實的證據......對我的上級的惱怒...... – 2015-05-19 21:53:41

在SQL Server中使用外鍵有嚴重的性能下降嗎？

回答

相關問題