SQL分庫分表

歷史背景

MySql性能瓶頸

1. 1.    表數據量過大
2. 2.    Sql查詢過於復雜
3. 3.    Sql沒走索引
4. 4.    數據庫服務器性能低

解決方案

阿里開發手冊：單表行數超過500W或者單表容量超過2G

數據庫分庫分表

1. 分庫分表
2. 冷熱數據分離
3. 歷史數據分離

數據庫分庫分表

1. 1.    垂直拆分
   1. 垂直分表（大表拆成多個小表）

 

 

 

優點

1. 防止單表字段過多產生頁分裂從而導致IO次數過多，效率差的問題
2. 可以達到最大化利用Cache的目的，具體在垂直拆分的時候可以將不常變的字段放一起，將經常改變的放一起

缺點

 1. 主鍵出現冗余，需要管理冗余例

 2. 會引起表連接JOIN操作(增加CPU開銷

 3. sql以及事務處理復雜

1. 垂直分庫（單個庫拆成多個庫  微服務系統）

 

 

 

優點

       分散單庫訪問壓力

缺點

            分布式事務問題

1. 2.    水平拆分
   1. 1.    水平分表

 

 

 

優點

1.單庫單表的數據能保持在一定的量級，有助於性能的提高。
2.切分的表結構相同，應用層改造較少，只需要增加路由規則即可。
3.提高了系統的穩定性和負載能力。

缺點

1. 切分后，數據是分散的，跨庫join操作難和性能差
2. 拆分規則難以抽象
3. 分片事務的一致性難以解決
4. 數據擴容的難度和維護量極大
5. 2.    水平分庫

 

 

 

分庫分表算法

1. 1.    哈希取模算法

 

 

 

優點

   算法簡單，數據分布相對均勻

缺點

   擴容問題，需要哈希取模全部數據遷移（比如增加user_05,算法變成id%5,01-04里面數據全部需要重新分布）

1. 2.    一致性哈希算法

 

 

 

 

 

 

當B需要移除時

 

 

 

hash環的偏斜

在實際的映射中，服務器可能會被映射成如下模樣。

 

 

 

如果服務器被映射成上圖中的模樣，那么被緩存的對象很有可能大部分集中緩存在某一台服務器上，如下圖所示。

 

 

 

虛擬節點（定義虛擬節點，讓哈希環分布均勻）

 

 

 

 

 

1. 3.    按照范圍分片算法（按照不同的數據業務特性定義分片鍵）
   1. 按照商家
   2. 按照時間月份
   3. 按照地域

案例

用戶表

1. 1.    功能

注冊，登錄，查詢，修改

1. 2.    使用范圍
   1. 1.    用戶端（用戶登錄，修改用戶，信息查詢）

1.根據用戶ID查詢用戶信息->90%

2.根據phone,email查詢用戶信息->10%

1. 2.    管理員端
   1. 統計用戶信息
   2. 查詢條件多變查詢

可以根據用戶ID進行分片

 

 

 

 

分庫分表中間件

1. 1.    分庫分表組件（Sharding-JDBC 代碼實現）

 

 

 

1. 2.    服務端代理(MyCat)

 

 

 

分庫分表問題

1. 1.    歷史數據遷移
2. 2.    復雜SQL聯合查詢
3. 3.    分頁問題
4. 4.    事務問題