業(yè)務分庫
按照業(yè)務分庫折砸，比如用戶看疗、商品、訂單分庫
帶來的問題
- join 問題
不在同一數(shù)據(jù)庫無法join睦授，只能先查一個數(shù)據(jù)庫拿到id列表两芳，在去另外一個庫查詢 - 事務問題
原本在同一個數(shù)據(jù)庫的不同表的操作可以在同一個事務里邊，分散到不同數(shù)據(jù)庫后無法通過事務統(tǒng)一修改去枷。 - 成本問題
分表
- 垂直分表
把不常用且占用了大量空間的列拆分出去怖辆。帶了的問題是原來只要查詢一次就能獲取所有所有列，現(xiàn)在需要查詢多次 - 水平分表
-
路由
- 范圍路由
按照userId的范圍分表沉填，特點可能分配不均（例如按照1000萬分表疗隶，可能一個表有1000萬另一個表只有1000），隨著數(shù)據(jù)的增加平滑的擴充新表翼闹，原數(shù)據(jù)不動 - hash路由
按照hash取模分表斑鼻，特點分配均勻，但是新增表所有數(shù)據(jù)需要重新分布猎荠，但是使用一致性hash算法可以優(yōu)化 - 配置路由
增加一個配置表比如 user_router表 包含 user_id,table_id兩列,優(yōu)點靈活坚弱，缺點多查詢一次表太大了性能也會不好
- 范圍路由
join
需要多次join然后合并count()
多個表count()相加，實現(xiàn)簡單去誒單性能較低关摇。增加一個記錄數(shù)表荒叶，性能優(yōu)化了，但是復雜度增加了输虱，必須要同步記錄些楣，但是又不能放在同一事務里處理，因為記錄表插入失敗不應該回滾業(yè)務邏輯order by
數(shù)據(jù)分散多個字表中宪睹，排序無法在數(shù)據(jù)庫中完成愁茁，只能由業(yè)務或者中間件去分表查詢每個子表中的數(shù)據(jù)然后匯總。
