跨庫架構演進：從分庫策略到外鍵移除與冗余設計權衡

前置準備：命名規範與外鍵抉擇

預先為各業務模組表名加上前綴（如 BBS_、BLOG_），分庫時可依前綴快速歸類。然而分庫勢必面臨外鍵約束失效問題——跨庫無法建立外鍵，必須果斷移除。

挑戰一：跨庫 JOIN 如何處理？

場景

部落格列表需顯示用戶名，原先同庫可 INNER JOIN User，分庫後用戶表與部落格表分處不同資料庫。

方案比較

建議：初期可採方案一快速上線；長期演進建議導入方案二，以快取層統一解決跨庫關聯查詢。

挑戰二：級聯刪除與觸發器的替代

• 級聯刪除：屬資料庫隱含邏輯，難以追蹤與維護。改由應用層程式碼顯式處理，刪除部落格時同步刪除評論、標籤關聯等。
• 觸發器：同樣屬隱含邏輯，同樣移至應用層，利用領域事件或服務協調完成衍生操作。

分庫後的擴展路徑

分庫本身不保證效能提升，關鍵在於將分出的庫遷移至獨立實體伺服器，讓 CPU、I/O、記憶體資源物理隔離，真正實現負載分攤。

決策原則

「分庫與否」取決於資料量級與效能指標（QPS、延遲、併發）。未達瓶頸前勿過度設計；達標後以「業務邊界」為單位分庫，配合快取與讀寫分離，構建可水平擴展的資料層架構。