分庫分表的種類：
   這里說的分庫分表是把數據庫中的數據物理地拆分到多個實例或者多臺服務器上，而不是MySQL原生的Partitioining。
   MySQL官方的Partitioning可以將一張表的數據庫分別存儲為多個文件，如果在寫SQL的時候遵從了分區規則，就能把原本需要遍歷全表的工作轉化為只需要遍歷表里一個或者部分分區的工作，這樣就降低了查詢對服務器的壓力。但是這樣不管怎么分區，所有數據都在一個服務器上邊，沒有辦法通過水平擴展物理服務的方法把壓力分攤出去。
垂直拆分：
   考慮數據庫拆分的時候，首先考慮垂直拆分，其次考慮水平拆分。垂直拆分可以理解為分出來的庫表結構是互相獨立各不相同的。
1）如果有多個業務，業務之間的關聯性不大，就可以把不同業務拆分為單獨的實例，庫或表。
2）如果在一個實例上邊，有多個數據庫，可以把每個數據庫拆分到單獨的實例上。
3）如果一個庫中有多張表，可以把每張表拆分到不同的實例上。
4）如果有一張表，但表里字段太多，當表太大的時候，可以把每個或者幾個字段拆分為一個表。
水平拆分：
   水平拆分是針對一張表說的，在經過垂直拆分之后，如果表的數據庫依然過大，例如注冊用戶量超過10億，那只好通過某種算法進行水平拆分。拆分之后結果是多張具有相同表結構的表，每張表里存儲一部分數據。拆分的方法依據很多，例如通過取模100、2014等。
分庫分表的原則：
原則零：能不分就不分
如果能對系統進行升級來提升數據庫的性能，例如升級硬盤、cpu、內存、網絡、數據庫版本、讀寫分離、負載均衡等方面解決問題，就不要做分表分庫。也就是說做分表分庫的前提是這些已經做好了。
原則一：數據量太大，正常的運維影響正常的業務訪問。
1）對數據庫的備份，如單個表太大，做數據庫備份的時候需要大量的磁盤IO或者網絡IO資源。
2）對數據表的修改，如表數據庫太大，做DDL時候會對表加鎖，這個時間會很長。
3）整個表的熱點數據，如某表的user_last_login字段，頻繁進行update操作，導致此表壓力過大。
原則二：表設計不合理，對某些字段垂直拆分
1）用戶數從100萬飆升到10億，user_last_login字段不斷被update，最好的辦法就是把該字段垂直拆分出去。
2）用戶表的person_info 表本來沒什么用，但是有些用戶會把個人信息填寫的分成完善，更糟糕的是產品經理心血來潮，要把該字段開放，其他所有人都可以訪問，而該字段的類型是text，這個必須要進行拆分。
原則三：某些數據出現了無窮盡的增長
比如聊天系統的聊天記錄，充值系統的充值記錄等等。
原則四：安全性和可用性的考慮
不要把所有雞蛋都放在一個籃子里，我們不希望數據庫出問題，或者不希望100%的用戶受到影響。如把用戶、庫存、訂單等本來統一的資源進行拆分。
原則五：業務耦合性考慮
火車票業務和烤羊腿業務不沾邊，完全可以拆分為不同的數據庫。

當前名稱：MySQL分庫分表
文章來源：http://www.xueling.net.cn/article/jggjsj.html