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