關于MySQL分庫分表緣由

關于分庫分表,要關心硬體,業務,分布式,和資料庫選型.

   基本名額:庫實體檔案大小<100G

   表<100

   字段<200

   單表記錄數<500W

   分庫分表直接目的是要控制表的數量，控制資料的容量，最終的目的是降低響應延遲，更容易的運維

   可以用說用到MySQL的地方,隻要資料量一大, 馬上就會遇到一個問題,要分庫分表.這裡引用一個問題為什麼要分庫分表呢?MySQL處理不了大的表嗎?其實是可以處理的大表的.我所經曆的項目中單表實體上檔案大小在80G多,單表記錄數在5億以上,而且這個表屬于一個非常核用的表:朋友關系表.但這種方式可以說不是一個最佳方式. 因為面臨檔案系統如Ext3檔案系統對大于大檔案處理上也有許多問題.

   這個層面可以用xfs檔案系統進行替換.但MySQL單表太大後有一個問題是不好解決: 表結構調整相關的操作基本不在可能.是以大項在使用中都會面監着分庫分表的應用.

   分庫分表還就是一個比較好的選擇

   那麼分庫分表多少合适呢?

   經測試在單表1000萬條記錄一下,寫入讀取性能是比較好的. 這樣在留點buffer,那麼單表全是數字類型的保持在

   800萬條記錄以下, 有字元型的單表保持在500萬以下.如果按 100庫100表來規劃,如使用者業務:

500萬*100*100 = 50000000萬 = 5000億記錄.心裡有一個數了,按業務做規劃還是比較容易的.

   分庫的原因，更多的為将來擴充及性能考慮．一個程序下打開的檔案句柄有限，這是分庫分表要限制在單個程序下的數量．當然這些表也可以全放到一個庫下．但引入另外一個問題，單機性能達到瓶頸時，擴充又是一個麻煩事．　是以引入了一個分庫，這樣，才開始時，所有的庫都可以在一個事例下，等到壓力增大後，單機成為瓶頸了，可以通過移庫的形式能快速的移動資料．這個要看單機的容量, 如果單機IO不是問題如果Fusion-io這種IO裝置+SAS ,單庫可以達到800G甚至1T都沒問題.如果是傳統的SAS建議單機單庫别超過200G. 如果可能控制在100G以内,不然不容易運維.

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1332650，如需轉載請自行聯系原作者