分庫分表使用場景及設計方式

一. 分表

      場景：對於大型的互聯網應用來講，數據庫單表的記錄行數可能達到千萬級甚至是億級，而且數據庫面臨着極高的併發訪問。採用Master-Slave複製模式的MySQL架構，只可以對數據庫的讀進行擴展，而對數據庫的寫入操做仍是集中在Master上，而且單個Master掛載的Slave也不可能無限制多，Slave的數量受到Master能力和負載的限制。

　　所以，須要對數據庫的吞吐能力進行進一步的擴展，以知足高併發訪問與海量數據存儲的須要！

　　對於訪問極爲頻繁且數據量巨大的單表（百萬到千萬級別）來講，咱們首先要作的就是減小單表的記錄條數，以便減小數據查詢所須要的時間，提升數據庫的吞吐，這就是所謂的分表！

　　在分表以前，首先須要選擇適當的分表策略，使得數據可以較爲均衡地分不到多張表中，而且不影響正常的查詢！ 

　　對於互聯網企業來講，大部分數據都是與用戶關聯的，所以，用戶id是最經常使用的分表字段。由於大部分查詢都須要帶上用戶id，這樣既不影響查詢，又可以使數據較爲均衡地分佈到各個表中(固然，有的場景也可能會出現冷熱數據分佈不均衡的狀況)，以下圖：

　　假設有一張表記錄用戶購買信息的訂單表order，因爲order表記錄條數太多，將被拆分紅256張表。

　　拆分的記錄根據user_id%256取得對應的表進行存儲，前臺應用則根據對應的user_id%256，找到對應訂單存儲的表進行訪問。（即id除以256餘數爲0則查0號表）

　　這樣一來，user_id便成爲一個必需的查詢條件，不然將會因爲沒法定位數據存儲的表而沒法對數據進行訪問。

　　注：拆分後表的數量通常爲2的n次方，就是上面拆分紅256張表的由來！

舉例：

假設order表結構以下：

 1 create table order_(
 2  order_id bigint(20) primary key auto_increment,
 3  user_id bigint(20),
 4  user_nick varchar(50),
 5  auction_id bigint(20),
 6  auction_title bigint(20),
 7  price bigint(20),
 8  auction_cat varchar(200),
 9  seller_id bigint(20),
10  seller_nick varchar(50)
11 )

　　那麼分表之後，假設user_id = 257,而且auction_id = 100,須要根據auction_id來查詢對應的訂單信息，則對應的SQL語句以下：

select * from order_1 where user_id=257 and auction_id = 100;

　　其中，order_1是根據257%256計算得出，表示分表以後的第一張order表。

二. 分庫

　　場景：分表可以解決單表數據量過大帶來的查詢效率降低的問題，可是，卻沒法給數據庫的併發處理能力帶來質的提高。面對高併發的讀寫訪問，當數據庫master服務器沒法承載寫操做壓力時，無論如何擴展slave服務器，此時都沒有意義了。

　　所以，咱們必須換一種思路，對數據庫進行拆分，從而提升數據庫寫入能力，這就是所謂的分庫!

　　與分表策略類似，分庫能夠採用經過一個關鍵字取模的方式，來對數據訪問進行路由，以下圖所示：

 

　　仍是以前的訂單表，假設user_id 字段的值爲258，將原有的單庫分爲256個庫，那麼應用程序對數據庫的訪問請求將被路由到第二個庫(258%256 = 2)。

三. 分庫分表

　　場景：有時數據庫可能既面臨着高併發訪問的壓力，又須要面對海量數據的存儲問題，這時須要對數據庫既採用分表策略，又採用分庫策略，以便同時擴展系統的併發處理能力，以及提高單表的查詢性能，這就是所謂的分庫分表。

    分庫分表的策略比前面的僅分庫或者僅分表的策略要更爲複雜，一種分庫分表的路由策略以下：

1. 中間變量 = user_id % (分庫數量 * 每一個庫的表數量)
2. 庫 = 取整數 (中間變量 / 每一個庫的表數量)
3. 表 = 中間變量 % 每一個庫的表數量

 

　　一樣採用user_id做爲路由字段，首先使用user_id 對庫數量*每一個庫表的數量取模，獲得一箇中間變量；而後使用中間變量除以每一個庫表的數量，取整，便獲得對應的庫；而中間變量對每一個庫表的數量取模，即獲得對應的表。

分庫分表策略詳細過程以下：

 假設將原來的單庫單表order拆分紅256個庫，每一個庫包含1024個表，那麼按照前面所提到的路由策略，對於user_id=262145 的訪問，路由的計算過程以下：

1. 中間變量 = 262145 % (256 * 1024) = 1
2. 庫 = 取整 (1/1024) = 0
3. 表 = 1 % 1024 = 1

 這就意味着，對於user_id=262145 的訂單記錄的查詢和修改，將被路由到第0個庫的第1個order_1表中執行！！！

四，橫分縱分

分表又分爲橫向分表和縱向分表

1）縱向分表

　　 將原本能夠在同一個表的內容，人爲劃分爲多個表。（所謂的原本，是指按照關係型數據庫的 第三範式要求，是應該在同一個表的。）

分表理由： 根據數據的活躍度進行分離，（由於不一樣活躍的數據，處理方式是不一樣的）

 

案例：

　　對於一個博客系統，文章標題，做者，分類，建立時間等，是 變化頻率慢， 查詢次數多，並且最好有很好的實時性 的數據，咱們把它叫作 冷數據。而博客的瀏覽量，回覆數等，相似的統計信息，或者別的 變化頻率比較高的數據，咱們把它叫作 活躍數據。因此，在進行數據庫結構設計的時候，就應該考慮分表，首先是 縱向分表的處理。

這樣縱向分表後：

　　首先存儲引擎的使用不一樣， 冷數據使用MyIsam 能夠有更好的查詢數據。 活躍數據，可使用Innodb,能夠有更好的更新速度。

　　其次， 對冷數據進行更多的 從庫配置，由於更多的操做時查詢，這樣來加快查詢速度。 對熱數據，能夠相對有更多的 主庫的橫向分表處理。

　　其實，對於一些 特殊的活躍數據，也能夠考慮使用memcache , redis之類的緩存，等累計到 必定量再去更新數據庫。或者mongodb 一類的nosql數據庫，這裏只是舉例，就先不說這個。

橫向分表

　　字面意思，就能夠看出來，是把大的表結構，橫向切割爲一樣結構的不一樣表，如，用戶信息表，user_1,user_2等。 表結構是徹底同樣，可是，根據某些特定的規則來劃分的表，如根據用戶ID來取模劃分。

　　分表理由： 根據數據量的規模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。

案例：

　　同上面的例子，博客系統。當博客的量達到很大時候，就應該採起橫向分割來下降每一個單表的壓力，來提高性能。例如博客的冷數據表，假如分爲100個表，當同時有100萬個用戶在瀏覽時，若是是單表的話，會進行100萬次請求，而如今分表後，就多是每一個表進行1萬個數據的請求（由於，不可能絕對的平均，只是假設），這樣壓力就下降了不少不少。

 

https://blog.csdn.net/yuxianjun2012/article/details/54846136 

https://blog.csdn.net/winy_lm/article/details/50708493