資料庫死結通常被視為執行時期的異常，是一種僅在高負載下才會出現的神秘錯誤。然而，深入檢視後會發現，根本原因經常出現在邏輯設計階段。實體關係模型（ERD）決定了資料如何被結構化、連結與存取。當資料庫結構設計未能考慮並發模式時，資料庫引擎便被迫陷入競爭狀態。本文探討如何透過優化ERD結構，事先化解死結風險，確保交易流程更順暢，系統穩定性更高。
🔍 模式設計與並發性的關聯
大多數開發人員都了解，當兩個交易各自持有對方所需的資源鎖時，就會產生死結，形成循環等待。然而，鎖定特定資料列、資料頁或資料表的決定，通常源自於底層的資料表關係。設計不良的ERD可能迫使資料庫引擎不必要地提升鎖的層級。
當您定義實體之間的關係時，便建立了資料完整性的規則。外鍵、級聯更新與檢查約束都會帶來額外負擔。如果模型與應用程式的存取模式不符，資料庫引擎必須執行更多工作以維持一致性。這額外的工作會延長交易的持續時間，而較長的交易會長時間持有鎖，增加與並行處理程序發生衝突的機率。
ERD影響鎖定行為的主要領域包括：
- 外鍵約束： 每當子資料記錄被更新或刪除時，父資料記錄通常需要鎖定以驗證參考完整性。
- 索引位置： ERD會指出哪些欄位經常被連結。關係欄位缺少索引會迫使進行資料表掃描，進而將鎖提升至更高層級。
- 正規化層級： 高度正規化的結構需要更多的連結。複雜的連結涉及多個資料表，增加了可能產生鎖衝突的範圍。
- 交易範圍： 該模型定義了哪些資料表會被同時存取。在單一交易中存取無關的資料表會導致資源碎片化，並引發競爭。
🔗 外鍵與鎖粒度
外鍵是關係完整性的重要支柱，但同時也是競爭的主要來源。當交易修改子資料表中的一筆資料時，資料庫必須確保父資料表中所參考的資料存在。此驗證過程需要鎖定父資料記錄。在高並發環境中，若多個交易同時嘗試修改同一父資料的多個子資料，它們可能會互相阻塞。
考慮一個訂單資料表參考客戶資料表的情境。若客戶資料表經常被更新（例如地址變更），而訂單資料表也經常被更新（例如狀態變更），共享的客戶記錄便會成為瓶頸。應檢視ERD，確認此種耦合是否必要。
透過設計來降低此風險的策略包括：
- 非同步驗證： 若並非每個微操作都需嚴格的參考完整性，可考慮將約束檢查移至背景程序執行。這能減少交易期間鎖定的時間。
- 解耦高寫入頻率的資料表： 若父資料表與子資料表都處於高寫入狀態，可考慮在子資料表中複製父資料表的鍵。如此一來，子資料表即可獨立修改，無需觸及父資料表，從而降低父資料表上的鎖競爭。
- 樂觀鎖定欄位： 不再僅依賴資料庫層級的外鍵鎖，可引入版本欄位。這將完整性檢查轉移至應用程式邏輯，通常能減少資料庫持有鎖的時間。
📉 正規化層級與讀寫平衡
第三正規化形式（3NF）是資料完整性的黃金標準，能最小化冗餘。然而，它並非總是高性能量交易系統的最佳選擇。高度正規化的結構需要多次連結才能取得相關資料。在交易中，連結多個資料表意味著必須在多個資料表上取得鎖。若各交易的存取順序不一致，死結便不可避免。
反之，高度反正規化的結構雖能減少連結次數，但會增加資料列的大小。較大的資料列可能導致頁面分割與增加I/O，同樣會影響效能。目標是在ERD支援最常見的存取模式的同時，避免引入不必要的複雜性。
在檢視ERD以評估死結風險時，應考慮以下權衡：
- 冗餘與一致性之間的權衡： 是否可以將訂單狀態直接儲存在訂單資料表中，而非透過連結狀態查閱表？這能減少連結次數與被鎖定的資料表數量。
- 關聯複雜度：避免在單一交易中形成關係鏈（A 連結到 B，B 連結到 C，C 連結到 D）。若可能，應將其拆分為獨立的邏輯操作。
- 讀取密集型與寫入密集型：若模型的某部分為讀取密集型，反規範化可能可以接受。若是寫入密集型，則應保持規範化，但需確保索引穩健。
🧩 邏輯循環引用與依賴鏈
當實體 A 依賴實體 B，而實體 B 又依賴實體 A 時，就會產生循環引用。雖然在某些特定的層級結構中可能合理，但在交易環境中卻極具危險性。若某筆交易試圖在同一範圍內更新兩個實體，資料庫必須先鎖定 A 再鎖定 B。若另一筆交易先鎖定 B 再鎖定 A，立即就會產生死鎖。
ERD 應當審查是否存在循環依賴。若存在循環，必須謹慎處理。在許多情況下，可將依賴關係移除或設為可選。
| 依賴模式 | 鎖定風險 | 設計緩解措施 |
|---|---|---|
| 直接自我引用 | 高 | 使用獨立的層級表或 ID 映射。 |
| 相互外鍵 | 嚴重 | 移除其中一個外鍵；透過應用程式邏輯強制執行。 |
| 深度鏈結（A→B→C→A） | 高 | 打破鏈結；拆分交易。 |
| 一對多且具更新級聯 | 中等 | 停用級聯更新；在應用程式中處理。 |
當循環引用無法避免時，應用程式層必須強制執行嚴格的鎖定順序。所有交易必須先鎖定實體 A 再鎖定實體 B。然而，依賴應用程式程式碼來確保鎖定順序極為脆弱。更安全的做法是盡可能重構 ERD 以消除循環。
🗺️ ERD 內的索引策略
索引不僅是效能工具，也是鎖定工具。ERD 定義了哪些欄位是外鍵與主鍵。這些欄位對於資料庫引擎快速定位資料至關重要。若 ERD 定義了關係，但對應欄位缺乏索引，引擎必須掃描整個資料表。資料表掃描所鎖定的資料列比尋找操作更多，進而增加阻擋其他交易的機率。
每個外鍵欄位都應建立索引。這是防止死鎖的基本原則。若無索引，資料庫可能將資料列鎖提升為資料表鎖，以執行完整性檢查。資料表鎖定具有顯著的限制性，並會使競爭情況呈指數級增加。
在建模階段應考慮以下索引相關事項：
- 外鍵索引：確保每個外鍵欄位都具有對應的索引。
- 複合鍵： 如果一個表格使用複合主鍵，請確保查詢以索引定義的順序存取欄位。這可防止索引掃描。
- 覆蓋索引： 對於頻繁的讀取操作，設計包含所需資料的索引。這可讓資料庫僅從索引中滿足查詢，避免查閱表格資料。
- 更新頻率： 避免對經常更新的欄位建立索引。每次更新都需重建索引，並在修改期間持有鎖。
🔄 事務範圍與資料存取順序
ERD 定義了資料的邊界，告訴你哪些表格應歸為一組。然而，它並未規定存取它們的順序。當兩個不同的程序以不同順序存取同一組表格時，死鎖經常發生。資料庫引擎無法在不等待的情況下解決此衝突，進而導致死鎖。
透過在設計 ERD 時考慮事務邊界，您可以引導應用程式邏輯。如果模型顯示表格 A 和表格 B 緊密耦合，則應以固定順序存取。如果表格 C 耦合鬆散，則應在獨立的事務中處理。
管理存取順序的最佳實務包括：
- 全域排序： 建立一個規範，確保表格始終以特定順序存取（例如按 ID 或字母順序）。
- 短暫事務： 將事務保持盡可能短。不要在資料庫事務中包含耗時的業務邏輯（例如 API 呼叫）。
- 批次操作： 不要逐一更新資料列，應進行批次處理。這可減少鎖定取得事件的數量。
- 一致的隔離等級： 使用滿足資料完整性需求的最低隔離等級。較高的隔離等級會持有鎖更久。
🛡️ 處理軟刪除與活躍記錄
許多系統使用軟刪除，將資料列標記為已刪除而非直接移除。此設計選擇對 ERD 有顯著影響。如果 ERD 包含刪除標誌，查詢通常會根據此標誌進行過濾。此標誌會成為許多事務的常見存取點。
如果每個事務都更新相同記錄上的 `is_deleted` 標誌，競爭會急劇上升。ERD 應考慮是否所有實體都必須使用軟刪除。對於高頻率的日誌或稽核追蹤，硬刪除可能更合適。對於客戶資料，軟刪除很常見，但需要仔細設計索引。
軟刪除建模的關鍵考量：
- 索引狀態標誌： 確保軟刪除標誌是索引的一部分。
- 關注點分離： 在可能的情況下，盡量將活躍記錄與已刪除記錄在邏輯上分離，以避免掃描整個表格。
- 背景清理： 不要依賴主要事務來清理已刪除的記錄。應使用獨立的程序來處理垃圾回收。
📊 設計調整摘要
改善實體關係模型以防止死鎖是一個系統性的過程。這需要超越資料儲存的立即需求，並考慮系統的執行時行為。透過解決外鍵約束、適當地進行資料正規化、管理索引，並定義明確的事務邊界，您可以建立一個能抵抗競爭的資料結構。
以下清單可引導您的審查：
- 所有外键都已建立索引嗎？
- 表之間是否存在循環依賴？
- 相關表的存取順序在整個應用程式中是否一致？
- 級聯更新能否移至應用程式邏輯中？
- 是否對共享的父記錄進行頻繁更新？
- 資料庫規範化程度是否適合讀寫比例？
採用這些做法並不能保證消除所有併發問題，因為硬體和負載各不相同。然而，它能消除死鎖的結構性原因。設計良好的模型可作為穩定系統的基礎，減少在開發週期後期對緊急修補和複雜鎖定邏輯的需求。