作者：Draveness
為什麼這麼設計（Why’s THE Design）是一系列關於計算機領域中程式設計決策的文章，我們在這個系列的每一篇文章中都會提出一個具體的問題並從不同的角度討論這種設計的優缺點、對具體實現造成的影響。如果你有想要了解的問題，可以在文章下面留言。
當我們想要持久化地儲存資料時，使用關係型資料庫往往都是最穩妥的選擇，這不僅因為今天的關係型資料庫種類非常豐富並且穩定，還因為不同社群對關係型資料庫的支援都非常完備。我們在前面的文章中曾經分析過 為什麼 MySQL 的自增主鍵不單調也不連續，這篇文章我們來分析關係型資料庫中另一個重要的概念 — 外來鍵（Foreign Key）。
在關係型資料庫中，外來鍵也被稱為關係鍵，它是關係型資料庫中提供關係表之間連線的多個列1，這一組資料列是當前關係表中的外來鍵，也必須是另一個關係表中的候選鍵（Candidate Key），我們可以透過候選鍵在當前表中找到唯一的元素2。在通常情況下，我們都會使用關係表中的主鍵作為其他表中的外來鍵，這樣才可以滿足關係型資料庫對外來鍵的約束。
圖 1 - 關係型資料庫與外來鍵
外來鍵不僅僅是資料庫表中的一個整數，它還提供了額外的一致性保證。因為資料庫往往是整個系統的真理之源（Source of Truth），所以保證資料的一致性和正確性非常重要，關係型資料庫雖然提供了外來鍵、觸發器等特性保證一致性，但是在今天的生產環境中卻很少被使用。
引用完整性（Referential Integrity）是資料的屬性，如果資料擁有該屬性，那麼資料中所有的引用都是合法的，在關係型資料庫的上下文中，這就意味著關係型資料庫中引用另一個表中的值必須存在3。
ALTER TABLE postsADD CONSTRAINT FOREIGN KEY （author_id）REFERENCES authors（id）；
上述 SQL 語句可以向關係表中增加外來鍵約束，該 SQL 語句的執行前提是 posts 表中存在 author_id 欄位。從 SQL 語句中的 CONSTRAINT 關鍵字我們也能推測出外來鍵不是一種資料型別，它是不同關係表之間的約束。
圖 2 - 無狀態服務與資料庫
不使用外來鍵的原因其實很簡單，MySQL、PostgreSQL 等關係型資料庫很難水平擴容，但是無狀態的服務往往都可以很容易地擴容。由於外來鍵等特性需要資料庫執行額外的工作，而這些操作會佔用資料庫的計算資源，所以我們可以將大部分的需求都遷移到無狀態的服務中完成以降低資料庫的工作負載。
根據更新和刪除時的行為不同，我們可以將外來鍵分成 RESTRICT、CASCADE 和 SET NULL 等幾種4，當我們為關係表中的欄位增加外來鍵約束時，需要指定外來鍵的型別，最常見的也就是 RESTRICT 和 CASCADE 兩種，其中 RESTRICT 為外來鍵的預設型別，不同型別的外來鍵會帶來不同的額外開銷，而這些額外開銷就是我們不使用外來鍵的理由：
使用 RESTRICT 會在更新或者刪除記錄時對外來鍵對應的記錄是否存在進行一致性檢查；
使用 CASCADE 會在更新或者刪除記錄時觸發級聯更新或者刪除操作；
注意：MySQL 中的 NO ACTION 和 RESTRICT 具有相同的語義5。
接下來我們會詳細介紹關係型資料庫如何處理上述兩種不同型別的外來鍵，而我們應該如何在應用中模擬這些功能。
一致性檢查
當我們使用預設的外來鍵型別 RESTRICT 時，在建立、修改或者刪除記錄時都會檢查引用的合法性。想要在 MySQL 等資料庫中觸發外來鍵的一致性檢查其實非常容易，假設我們的資料庫中包含 posts（id， author_id， content） 和 authors（id， name）兩張表，在執行如下所示的操作時都會觸發資料庫對外來鍵的檢查：
向 posts 表中插入資料時，檢查 author_id 是否在 authors 表中存在；
修改 posts 表中的資料時，檢查 author_id 是否在 authors 表中存在；
刪除 authors 表中的資料時，檢查 posts 中是否存在引用當前記錄的外來鍵；
作為專門用於管理資料的系統，資料庫與應用服務相比能夠更好地保證完整性，而上述的這些操作都是引入外來鍵帶來的額外工作，不過這也是資料庫保證資料完整性的必要代價。上述的這些分析都是理論上的定性分析，我們其實可以簡單的定量分析一下引入外來鍵對效能的影響。
在這裡我們在資料庫中同時建立 authors、posts 和 foreign_key_posts 三種表，如下所示，其中 posts 和 foreign_key_posts 兩個表中的列完全相同，只是 foreign_key_posts 表為 author_id 欄位增加了 RESTRICT 型別的外來鍵約束：
圖 3 - 外來鍵效能測試關係圖
我們先在 authors 表中插入一條記錄，隨後分別在 posts 和 foreign_key_posts中插入多條新資料列引用該條記錄，前者不會檢查外來鍵的合法性，而後者會做額外的檢查。你可以在 這裡 找到作者用來測試外來鍵額外開銷的 Go 語言程式碼6，經過多次基準測試，我們可以得到如下所示的結果：
BenchmarkBaseline-8 3770 309503 ns/opBenchmarkForeignKey-8 3331 317162 ns/opBenchmarkBaseline-8 3192 315506 ns/opBenchmarkForeignKey-8 3381 315577 ns/opBenchmarkBaseline-8 3298 312761 ns/opBenchmarkForeignKey-8 3829 345342 ns/opBenchmarkBaseline-8 3753 291642 ns/opBenchmarkForeignKey-8 3948 325239 ns/op
作者執行了 4 次外來鍵的基準測試，雖然 4 次測試的結果不是特別穩定，但是使用外來鍵的用例在每次測試中都明顯弱於不使用外來鍵的用例，外來鍵帶來的額外開銷分別為 ~2。47%、~0。02%、~10。41% 和 ~11。52%。這裡的基準測試只是一個比較簡單的定量分析，但是我們也可以從結果中看到大概的趨勢 — 外來鍵的完整性檢查確實會帶來額外的效能開銷，而這些開銷在高併發的服務中需要慎重考慮。
想要在應用程式中模擬資料庫外來鍵的功能其實比較容易，我們只需要遵循以下的幾個準則：
向表中插入資料或者修改表中的資料時，都應該執行額外的 SELECT 語句確保它引用的資料在資料庫中存在；
在刪除資料之前需要執行額外的 SELECT 語句檢查是否存在當前記錄的引用；
需要注意的是為了保證一致性，我們需要在事務中執行上述的查詢和修改語句，這樣才能完整模擬外來鍵的功能；當我們向 posts 表中插入或者修改資料時，需要的處理相對比較簡單，我們只需要執行有限的 SELECT 語句並按照如下所示的模式執行對應的操作就可以了：
BEGINSELECT * FROM authors WHERE id =
但是如果我們要刪除 authors 表中的資料，就需要查詢所有引用 authors 資料的表；如果有 10 個表都有指向 authors 表的外來鍵，我們就需要在 10 個表中查詢是否存在對應的記錄，這個過程相對比較麻煩，不過也是為了實現完整性的必要代價，不過這種模擬外來鍵方法其實遠比使用外來鍵更消耗資源，它不僅需要查詢關聯資料，還要透過網路傳送更多的資料包。
級聯操作
當我們在關係型資料庫中建立外來鍵約束時，如果使用如下所示的 SQL 語句指定更新或者刪除記錄時使用 CASCADE 行為，那麼在客戶端更新或者刪除資料時就會觸發級聯操作：
ALTER TABLE postsADD CONSTRAINT FOREIGN KEY （author_id）REFERENCES authors（id）ON UPDATE CASCADEON DELETE CASCADE；
當客戶端更新 authors 表中記錄的主鍵時，資料庫會同時更新 posts 表中所有引用該記錄的外來鍵；
當客戶端刪除 authors 表中的記錄時，資料庫會刪除所有與 authors 表關聯的記錄；
不過無論是執行更新還是刪除操作，資料庫都可以保證各個關係表之間引用的一致性和合法性不會出現引用到不存在記錄的情況，與 RESTRICT 行為一樣，所有外來鍵的更新和刪除行為都可以透過執行額外的檢查和操作保證資料的一致。
圖 4 - 複雜的級聯操作
雖然級聯刪除的出發點也是保證資料的完整性，但是在設計關係表之間的不同關係時，我們也需要注意級聯刪除引起的資料大規模刪除的問題。如上圖所示，當客戶端想要在資料庫中刪除 authos 表中的資料時，如果我們同時在 authors 和 posts中指定了級聯刪除的行為，那麼資料庫會同時刪除所有關聯的 posts 記錄以及與 posts 表關聯的 comments 資料。
這種涉及多級的級聯刪除行為在資料量較小的資料庫中不會導致問題，但是在資料量較大的資料庫中刪除關鍵資料可能會引起雪崩，一條記錄的刪除可能會被放大到幾十倍甚至上百倍，這些對磁碟的隨機讀寫會帶來巨大的開銷，是我們想要儘可能避免的情況。如果我們能夠較好地設計各個表之間的關係並且慎用 CASCADE 行為，這對於保證資料庫中資料的合法性有著很重要的意義，使用該特性可以避免資料庫中出現過期的、不合法的資料，但是在使用時也要
合理預估
可能造成的最壞情況。
手動實現資料庫的級聯刪除操作是可行的，如果我們在一個事務中按照順序刪除所有的資料，確實可以保證資料的一致性，但是這與外來鍵的級聯刪除功能沒有太大的區別，反而會有更差的表現。如果我們能夠接受在一個時間視窗內的資料不一致，就可以將一個大號的刪除任務拆成多個子任務分批執行，降低對資料庫影響的峰值。
DELETE FROM posts WHERE author_id = 1 LIMIT 100；DELETE FROM posts WHERE author_id = 1 LIMIT 100；。。。DELETE FROM authors WHERE id = 1；
與資料庫外來鍵的 CASCADE 相比，這種方式會帶來更大的額外開銷，只是我們能降低對資料庫效能的瞬時影響。
總結
外來鍵提供的幾種在更新和刪除時的不同行為都可以幫助我們保證資料庫中資料的一致性和引用合法性，但是外來鍵的使用也需要資料庫承擔額外的開銷，在大多數服務都可以水平擴容的今天，高併發場景中使用外來鍵確實會影響服務的吞吐量上限。在資料庫之外手動實現外來鍵的功能是可能的，但是卻會帶來很多維護上的成本或者需要我們在資料一致性上做出一些妥協。我們可以從可用性、一致性幾個方面分析使用外來鍵、模擬外來鍵以及不使用外來鍵的差異：
不使用外來鍵犧牲了資料庫中資料的一致性，但是卻能夠減少資料庫的負載；
模擬外來鍵將一部分工作移到了資料庫之外，我們可能需要放棄一部分一致性以獲得更高的可用性，但是為了這部分可用性，我們會付出更多的研發與維護成本，也增加了與資料庫之間的網路通訊次數；
使用外來鍵保證了資料庫中資料的一致性，也將全部的計算任務全部交給了資料庫；
在大多數不需要高併發或者對一致性有較強要求的系統中，我們可以直接使用資料庫提供的外來鍵幫助我們對資料進行校驗，但是在對一致性要求不高的、複雜的場景或者大規模的團隊中，不使用外來鍵也確實可以為資料庫減負，而大團隊也有更多的時間和精力去設計其他的方案，例如：分散式的關係型資料庫。
當我們考慮應不應該在資料庫中使用外來鍵時，需要關注的核心我們的資料庫承擔這部分計算任務後會不會影響系統的可用性，在使用時也
不應該一刀切
的決定用或者不用外來鍵，應該根據具體的場景做決策，我們在這裡介紹了兩個使用外來鍵時可能遇到的問題：
RESTRICT 外來鍵會在更新和刪除關係表中的資料時對外來鍵約束的合法性進行檢查，保證外來鍵不會引用到不存在的記錄；
CASCADE 外來鍵會在更新和刪除關係表中的資料時觸發對關聯記錄的更新和刪除，在資料量較大的資料庫中可能會有數量級的放大效果；
我們在很多時候其實並不能選擇是否使用外來鍵，大多數公司的 DBA 都會對資料庫系統的使用有比較明確的規定，但是我們要清楚做出使用外來鍵和不使用外來鍵這一抉擇的原因。到最後，我們還是來看一些比較開放的相關問題，有興趣的讀者可以仔細思考一下下面的問題：
資料庫中還有哪些特性是我們在生產環境中不會使用的？為什麼？
分散式的關係型資料庫與 MySQL 等傳統資料庫有哪些區別？
