在談論數據庫架構和數據庫優(yōu)化的時候，我們經常會聽到“分庫分表”、“分片”、“Sharding”…這樣的關鍵詞。讓人感到高興的是，這些朋友所服務的公司業(yè)務量正在（或者即將面臨）高速增長，技術方面也面臨著一些挑戰(zhàn)。讓人感到擔憂的是，他們系統(tǒng)真的就需要“分庫分表”了嗎？“分庫分表”有那么容易實踐嗎？為此，筆者整理了分庫分表中可能遇到的一些問題，并結合以往經驗介紹了對應的解決思路和建議。
垂直分表
垂直分表在日常開發(fā)和設計中比較常見，通俗的說法叫做“大表拆小表”，拆分是基于關系型數據庫中的“列”（字段）進行的。通常情況，某個表中的字段比較多，可以新建立一張“擴展表”，將不經常使用或者長度較大的字段拆分出去放到“擴展表”中，如下圖所示：
小結
在字段很多的情況下，拆分開確實更便于開發(fā)和維護（筆者曾見過某個遺留系統(tǒng)中，一個大表中包含100多列的）。某種意義上也能避免“跨頁”的問題（MySQL、MSSQL底層都是通過“數據頁”來存儲的，“跨頁”問題可能會造成額外的性能開銷，這里不展開，感興趣的朋友可以自行查閱相關資料進行研究）。
拆分字段的操作建議在數據庫設計階段就做好。如果是在發(fā)展過程中拆分，則需要改寫以前的查詢語句，會額外帶來一定的成本和風險，建議謹慎。
垂直分庫
垂直分庫在“微服務”盛行的今天已經非常普及了?；镜乃悸肪褪前凑諛I(yè)務模塊來劃分出不同的數據庫，而不是像早期一樣將所有的數據表都放到同一個數據庫中。如下圖：