關於分庫分表,要關心硬體,業務,分布式,和資料庫選型.
基本指標:庫物理檔案大小<100g
表<100
字段<200
單錶記錄數<500w
可以用說用到mysql的地方,只要資料量一大, 馬上就會遇到乙個問題,要分庫分表.
這裡引用乙個問題為什麼要分庫分表呢?mysql處理不了大的表嗎?
其實是可以處理的大表的.我所經歷的專案中單錶物理上檔案大小在80g多,單錶記錄數在5億以上,而且這個表
屬於乙個非常核用的表:朋友關係表.
但這種方式可以說不是乙個最佳方式. 因為面臨檔案系統如ext3檔案系統對大於大檔案處理上也有許多問題.
這個層面可以用xfs檔案系統進行替換.但mysql單錶太大後有乙個問題是不好解決: 表結構調整相關的操作基
本不在可能.所以大項在使用中都會面監著分庫分表的應用.
從innodb本身來講資料檔案的btree上只有兩個鎖, 葉子節點鎖和子節點鎖,可以想而知道,當發生頁拆分或是新增
新葉時都會造成表裡不能寫入資料.
所以分庫分表還就是乙個比較好的選擇了.
那麼分庫分表多少合適呢?
經測試在單錶1000萬條記錄一下,寫入讀取效能是比較好的. 這樣在留點buffer,那麼單錶全是數字型別的保持在
800萬條記錄以下, 有字元型的單錶保持在500萬以下.
如果按 100庫100表來規劃,如使用者業務:
500萬*100*100 = 50000000萬 = 5000億記錄.
心裡有乙個數了,按業務做規劃還是比較容易的.
分庫的原因，更多的為將來擴充套件及效能考慮． 效能是，乙個程序下開啟的檔案控制代碼有限，這是分庫分表要限制在單個程序下的數量．當然這些表也可以全放到乙個庫下．但引入另外乙個問題，單機效能達到瓶頸時，擴充套件又是乙個麻煩事． 所以引入了乙個分庫，這樣，才開始時，所有的庫都可以在事乙個事例下，等到壓力增大後，單機成為瓶頸了，可以通過移庫的形式能快速的移動資料．
這個要看單機的容量, 如果單機io不是問題如果fusion-io這種io裝置+sas ,單庫可以達到800g甚至1t都沒問題.如果是傳統的sas建議單機單庫別超過200g. 如果可能控制在100g以內,不然不容易運維.
關於MySQL分庫分表緣由
關於分庫分表,要關心硬體,業務,分布式,和資料庫選型.基本指標 庫物理檔案大小 100g 表 100 字段 200 單錶記錄數 500w 分庫分表直接目的是要控制表的數量，控制資料的容量，最終的目的是降低響應延遲，更容易的運維 可以用說用到mysql的地方,只要資料量一大,馬上就會遇到乙個問題,要分...
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...