一、分庫分表的背景
在數據爆炸的年代，單表數據達到千萬級別，甚至過億的量，都是很常見的情景。這時候再對數據庫進行操作就是非常吃力的事情了，select個半天都出不來數據，這時候業務已經難以維繫。不得已，分庫分表提上日程，我們的目的很簡單，減小數據庫的壓力，縮短表的操作時間。
二、如何進行數據切分
數據切分（Sharding），簡單的來說，就是通過某種特定的條件，將存放在同一個數據庫中的數據拆分存放到多個數據庫（主機）中，從而達到分散單臺機器負載的情況，即分庫分表。根據數據切分規則的不同，主要有兩種模式，
垂直切分（縱向切分），是對不同的表（或者Schema）進行切分，存儲到不同的數據庫（主機）之上。
水平切分（橫向切分），是對同一個表中的數據進行切分，存儲到不同的數據庫（主機）之上。規則是根據表中數據的邏輯關係，按照某種條件拆分。
垂直切分
垂直切分，強調的是業務的拆分。一個數據庫由多個表構成，每個表對應不同的業務，那麼我們可以指按照業務的不同將表進行分類，並將其分佈到不同的數據庫上，這樣就將數據分攤到了不同的庫上面，做到專庫專用。
舉個例子，原數據庫中有商品表、交易表、訂單表，我們可以按照業務的不同進行垂直切分，把商品表、交易表、訂單表分別拆分到商品庫、交易庫、訂單庫中去。
垂直拆分的優點：
拆分規則明確，拆分後業務清晰；系統之間進行整合或擴展變的容易；數據維護變的容易；按照成本、應用的等級、應用的類型等將表放到不同的機器上，便於管理。垂直拆分的缺點：
部分業務表無法關聯（Join），只能通過接口方式解決，提高了系統的複雜度；受每種業務的不同限制，存在單庫性能瓶頸，不易進行數據擴展和提升性能；分佈式事務處理複雜。水平切分（重點）
水平切分，強調的是技術層面的拆分。她是將其按照一定的邏輯規則將一個表中的數據分散到多個庫中，在每個表中包含一部分數據，所有表加起來就是全量的數據。簡單來說，我們可以將對數據的水平切分理解爲按照數據行進行切分，就是將表中的某些行切分到一個數據庫表中，而將其他行切分到其他數據庫表中。
比如，原數據庫有一張交易記錄表，數據量非常大，其中表中有個地區字段，經過深入考證符合水平拆分的條件。我們就按照這個字段進行水平拆分，按不同的地區（北京、上海、江蘇、浙江、廣東等）拆分成10個庫。
高峯時段同時有100萬次請求，如果是單庫，數據庫就會承受100萬次的請求壓力，拆分成100個表分別放入10個庫中，每個表進行1萬次請求，則每個數據庫會承受10萬次的請求壓力，這樣壓力就減少了很多，並且是成倍減少的。
水平拆分的優點：
拆分規則抽象好，join 操作基本可以數據庫做；不存在單庫大數據，高併發的性能瓶頸；應用端改造較少；提高了系統的穩定性跟負載能力。水平拆分的缺點：
拆分規則不好抽象；分片事務一致性難以解決；數據多次擴展難度大；跨庫 join 性能較差。三、數據切分導致的一些問題
上面我們也講了兩種數據切分方式的優點和缺點，但是他們有些共同的缺點，
分佈式事務的問題；跨節點 Join 的問題；跨節點合併排序分頁的問題；多數據源管理問題。一般來說，業務上存在着複雜 join 的場景是很難切分的，往往業務獨立的易於切分。如何切分，我們遵循如下原則，
能不切分儘量不要切分；如果要切分一定要選擇合適的切分規則，提前規劃好；數據切分儘量通過數據冗餘或表分組來降低跨庫 Join 的可能；由於數據庫中間件對數據 Join 實現的優劣難以把握，而且實現高性能難度極大，業務讀取儘量少使用多表 Join。四、數據源管理的問題
分庫分表之後，數據源的管理是系統實現的關鍵。
系統應用層面系統應用代碼層面，目前主要有兩種思路，
客戶端模式，也就是在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合。比如可以依賴spring註解實現。中間代理模式，統一管理所有的數據源，後端數據庫集羣對前端應用程序透明。考慮到系統的複雜性和擴展性，建議第二種中間代理模式。雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常實用的。
2. 中間件層面
上面的系統層面，需要的代碼實現比較複雜，中間件是在數據集羣前面加一層代理，比如Cobar、Mycat等數據庫中間件。實用數據庫中間件，對代碼層面的實現是很大的解放。
五、分佈式事務的解決方案
分庫分表導致的最突出的問題就是分佈式事務的處理。大家如果有興趣可以參考下之前的文章互聯網架構下的分佈式技術面試要點概覽中的分佈式事務部分，後面如果有時間，可以單獨再探討下。