一、在業務層保證數據一致性沒有性能問題

因為業務層做就意味著數據庫不需要為這個事做事務保證，而是業務自己負責，通常來說業務層會使用消息隊列、事務補償等在一致性上做出讓步的”柔性事務”來做。這樣一來業務關鍵路徑上的邏輯將變輕，總體延遲和TPS數據更好看。當然如果你不想放棄強一致性的話，還是在數據庫層做更好，業務層要干這事，那性能會慘不忍睹。

外鍵保證的是數據更新符合約束的定義，也就是更新過程中通過一些檢查來避免和約束沖突的情況出現。

但是，就像我們會在代碼里寫assert一樣，有一些情況是我們確信不會發生的，那就可以不要約束，或者自己加一些管理來做到約束，所以很多程序會通過應用層來保障寫入數據不會違反約束，這么做當然繁瑣，不如數據庫本身可靠高效。

那么大家這么做的最大動機是啥，是提高執行速度？ “去掉外鍵約束是提高執行速度的最簡單粗暴的辦法”，速度先提升上來，有什么坑可以在應用層修修補補，雖然最后修補出來的結果不一定有數據庫本身約束的情況快。

以上，去掉外鍵的原因不是它對性能影響最大，而是眾多因素當中外鍵是較好改的一個。

延伸閱讀：

二、數據庫中的概念

Table：數據庫中的表，下文稱“table”或者“表”。

Column：表中的各個字段，下文稱“column”或者“列”或者“字段”。

Row：表中的各條記錄，下文稱“row”或者“行”

Index：表中的索引，用戶可以建立索引以便加速搜索，但是用戶無法直接使用索引，下文稱“index”或者“索引”。

View：數據庫中的視圖，一種由實際的表導出的可視化的表，并不實際存儲。

Virtual table：虛擬表是一種表現得像表的對象，從SQL語句的角度看，虛表可以和表或者view一樣操作，但是對虛擬表的查詢或者修改操作會調用注冊在虛擬表上的回調函數，虛擬表機制使程序可以提供類似于SQL的表的接口供SQL語句操作。隱藏在虛擬表下的數據結構可能是內存中的數據，或者通過即時運算得出的結果，或者是磁盤上的文件（比如CSV）。下文稱“virtual table”或者“虛擬表”。

Shadow table：FTS（全文搜索）中所使用的每個virtual table，都有3-5個真實的數據庫的table（分別名為%_content、%_segdir、%_segment、 %_stat、%_docsize，%是FTS virtual table的名字）來在實現，這些table被稱為shadow table。

Trigger：數據庫中的觸發器，由修改數據庫的事件觸發的存儲過程，下文稱“觸發器”或者“trigger”。

Schema：SQLite數據庫的結構（有哪些table/index/view/trigger，分別有哪些字段），下文稱“schema”。

Rowid：rowid是SQLite中的表隱含的一個column，是其內部id，在該表中少數，是SQLite中的元數據。

Statement：SQL語句。

Prepared statement：經過“預備”的SQL語句，所謂“預備”類似編譯，可以再多次執行同一語句的時候加速（跳過“預備”過程）。

sqlite_master：sqlite數據庫中維護的系統表，該表的b-tree的根頁號永遠為1，有5個列，分別是類型（table, view, index,trigger，四者之一）、名稱、所在表名、根頁號、SQL語句。

Journal：日志

Transaction：事務是用戶定義的一系列數據庫操作，要么全部執行，要么全部不執行。

Magic?string：類似“魔數/幻數”，SQLite數據庫文件特征頭。

Fraction

Auto-vacuum：自動清空

Incremental-vacuum

BLOB：Binary Large OBject