隨着業務的增長，一般的公司都會經歷一個從單庫單表到分庫分表的過程 , 需要考慮以下要素判斷是否開始分庫分表
1. 如果mysql單庫的QPS超過1000就要考慮分庫了 , 一般根據業務進行分庫
目前新浪郵箱的主庫是sinanet 各種輔助庫 userservice客服系統 sinastore 文件存儲庫 entsales 銷售系統庫
2. 單表的數據量非常大時 , 需要考慮分表 , 超過1000萬就要考慮了 , 因為此時b+樹索引的高度是3-5左右
如果有單字段特別大 , 就要把該字段獨立出來 ,這就是垂直分表 , 遵循冷熱拆分 , 大小拆分
這里基本在設計的時候就已經考慮好了 , 一般不會出現這種情況
如果是數據量特別大 , 就要結合業務需求和產品特性 , 選擇合適的拆分算法
如何切分？
a：哈希取模算法 hash(id)/NUM，
本表的id是數據庫auto_incr id，hash拆分后數據分散是特別均勻的，但是后面的NUM設置沒有經驗值，只能依靠人工來計算; max_row/day_incr= year ，保證能扛住近四年的數據增量。
考慮到后續擴展表的數據時，數據遷移會比較難做。
新浪郵箱的用戶表是根據默認域郵箱hash取模進行的拆分
b：一致性hash算法
為了保證后續遷移數據影響面較小，建議使用一致性hash算法。
新浪郵箱的訂單表是根據一致性hash算法根據 , 不同值的范圍大小選擇存儲表節點
c：range(timestamp)
具有天然的時間字段，非常好拆分，具有很好的擴展性。
目前查詢都是帶時間戳的，所以會出現表的訪問冷熱不均。但同時也避免了跨節點join等問題
新浪郵箱用戶的日志表是根據月份加哈希拆分了 1024張表
如何遷移數據？
這是不可避免的問題，可以采用了實時數據雙寫，歷史數據采用腳本導入的方式，在線上數據對齊后，慢慢將流量灌到新的db上。