可以用說用到MySQL的地方,只要數(shù)據(jù)量一大, 馬上就會遇到一個(gè)問題,要分庫分表.

     這里引用一個(gè)問題為什么要分庫分表呢?MySQL處理不了大的表嗎?

     其實(shí)是可以處理的大表的.我所經(jīng)歷的項(xiàng)目中單表物理上文件大小在80G多,單表記錄數(shù)在5億以上,而且這個(gè)表屬于一個(gè)非常核用的表:朋友關(guān)系表.

    但這種方式可以說不是一個(gè)最佳方式. 因?yàn)槊媾R文件系統(tǒng)如Ext3文件系統(tǒng)對大于大文件處理上也有許多問題.

     這個(gè)層面可以用xfs文件系統(tǒng)進(jìn)行替換.但MySQL單表太大后有一個(gè)問題是不好解決: 表結(jié)構(gòu)調(diào)整相關(guān)的操作基本不在可能.所以大項(xiàng)在使用中都會面監(jiān)著分庫分表的應(yīng)用.

    從Innodb本身來講數(shù)據(jù)文件的Btree上只有兩個(gè)鎖, 葉子節(jié)點(diǎn)鎖和子節(jié)點(diǎn)鎖,可以想而知道,當(dāng)發(fā)生頁拆分或是添加新葉時(shí)都會造成表里不能寫入數(shù)據(jù).

     所以分庫分表還就是一個(gè)比較好的選擇了.

    那么分庫分表多少合適呢?

     經(jīng)測試在單表1000萬條記錄一下,寫入讀取性能是比較好的. 這樣在留點(diǎn)buffer,那么單表全是數(shù)據(jù)字型的保持在800萬條記錄以下, 有字符型的單表保持在500萬以下.

    如果按 100庫100表來規(guī)劃,如用戶業(yè)務(wù):

     500萬*100*100 = 50000000萬 = 5000億記錄.

    心里有一個(gè)數(shù)了,按業(yè)務(wù)做規(guī)劃還是比較容易的.