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

文章標(biāo)題：MySQL分庫分表
網(wǎng)站網(wǎng)址：http://weahome.cn/article/jggjsj.html