2. 程式人生 > >MySQL分庫分表

MySQL分庫分表

阿新 • • 發佈：2018-05-01
ref 點擊 ace 技術 HERE atom hash 部分 function

相關文章：

1、 使用Spring AOP實現MySQL數據庫讀寫分離案例分析

2、MySQL5.6 數據庫主從（Master/Slave）同步安裝與配置詳解

3、MySQL主從復制的常見拓撲、原理分析以及如何提高主從復制的效率總結

4、使用mysqlreplicate命令快速搭建 Mysql 主從復制

5、大型網站應用之海量數據和高並發解決方案總結一二

一、MySQL擴展具體的實現方式

隨著業務規模的不斷擴大，需要選擇合適的方案去應對數據規模的增長，以應對逐漸增長的訪問壓力和數據量。

關於數據庫的擴展主要包括：業務拆分、主從復制，數據庫分庫與分表。這篇文章主要講述數據庫分庫與分表

（1）業務拆分

在 大型網站應用之海量數據和高並發解決方案總結一二 一篇文章中也具體講述了為什麽要對業務進行拆分。

業務起步初始，為了加快應用上線和快速叠代，很多應用都采用集中式的架構。隨著業務系統的擴大，系統變得越來越復雜，越來越難以維護，開發效率變得越來越低，並且對資源的消耗也變得越來越大，通過硬件提高系統性能的方式帶來的成本也越來越高。

因此，在選型初期，一個優良的架構設計是後期系統進行擴展的重要保障。

例如：電商平臺，包含了用戶、商品、評價、訂單等幾大模塊，最簡單的做法就是在一個數據庫中分別創建users、shops、comment、order四張表。

技術分享圖片

但是，隨著業務規模的增大，訪問量的增大，我們不得不對業務進行拆分。每一個模塊都使用單獨的數據庫來進行存儲，不同的業務訪問不同的數據庫，將原本對一個數據庫的依賴拆分為對4個數據庫的依賴，這樣的話就變成了4個數據庫同時承擔壓力，系統的吞吐量自然就提高了。

技術分享圖片

（2）主從復制

1、MySQL5.6 數據庫主從（Master/Slave）同步安裝與配置詳解

2、MySQL主從復制的常見拓撲、原理分析以及如何提高主從復制的效率總結

3、使用mysqlreplicate命令快速搭建 Mysql 主從復制

上述三篇文章中，講述了如何配置主從數據庫，以及如何實現數據庫的讀寫分離，這裏不再贅述，有需要的選擇性點擊查看。

技術分享圖片

上圖是網上的一張關於MySQL的Master和Slave之間數據同步的過程圖。

主要講述了MySQL主從復制的原理：數據復制的實際就是Slave從Master獲取Binary log文件，然後再本地鏡像的執行日誌中記錄的操作。由於主從復制的過程是異步的，因此Slave和Master之間的數據有可能存在延遲的現象，此時只能保證數據最終的一致性。

（3）數據庫分庫與分表

我們知道每臺機器無論配置多麽好它都有自身的物理上限，所以當我們應用已經能觸及或遠遠超出單臺機器的某個上限的時候，我們惟有尋找別的機器的幫助或者繼續升級的我們的硬件，但常見的方案還是通過添加更多的機器來共同承擔壓力。

我們還得考慮當我們的業務邏輯不斷增長，我們的機器能不能通過線性增長就能滿足需求？因此，使用數據庫的分庫分表，能夠立竿見影的提升系統的性能，關於為什麽要使用數據庫的分庫分表的其他原因這裏不再贅述，主要講具體的實現策略。請看下邊章節。

二、分表實現策略

關鍵字：用戶ID、表容量

對於大部分數據庫的設計和業務的操作基本都與用戶的ID相關，因此使用用戶ID是最常用的分庫的路由策略。用戶的ID可以作為貫穿整個系統用的重要字段。因此，使用用戶的ID我們不僅可以方便我們的查詢，還可以將數據平均的分配到不同的數據庫中。（當然，還可以根據類別等進行分表操作，分表的路由策略還有很多方式）

接著上述電商平臺假設，訂單表order存放用戶的訂單數據，sql腳本如下（只是為了演示，省略部分細節）：

CREATE TABLE `order` (
  `order_id` bigint(32) primary key auto_increment,
  `user_id` bigint(32),
   ...
)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

當數據比較大的時候，對數據進行分表操作，首先要確定需要將數據平均分配到多少張表中，也就是：表容量。

這裏假設有100張表進行存儲，則我們在進行存儲數據的時候，首先對用戶ID進行取模操作，根據 user_id%100 獲取對應的表進行存儲查詢操作，示意圖如下：

技術分享圖片

例如，user_id = 101 那麽，我們在獲取值的時候的操作，可以通過下邊的sql語句：

select * from order_1 where user_id= 101
  • 1
  • 1

其中，order_1是根據 101%100 計算所得，表示分表之後的第一章order表。

註意：

在實際的開發中，如果你使用MyBatis做持久層的話，MyBatis已經提供了很好得支持數據庫分表的功能，例如上述sql用MyBatis實現的話應該是：

接口定義：


/**
  * 獲取用戶相關的訂單詳細信息
  * @param tableNum 具體某一個表的編號
  * @param userId 用戶ID
  * @return 訂單列表
  */
public List<Order> getOrder(@Param("tableNum") int tableNum,@Param("userId") int userId);
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

xml配置映射文件：

<select id="getOrder" resultMap="BaseResultMap">
    select * from order_${tableNum}
    where user_id = #{userId}
  </select>
  • 1
  • 2
  • 3
  • 4
  • 1
  • 2
  • 3
  • 4

其中${tableNum} 含義是直接讓參數加入到sql中，這是MyBatis支持的特性。

註意：

另外，在實際的開發中，我們的用戶ID更多的可能是通過UUID生成的，這樣的話，我們可以首先將UUID進行hash獲取到整數值，然後在進行取模操作。
  • 1
  • 1

三、分庫實現策略

數據庫分表能夠解決單表數據量很大的時候數據查詢的效率問題，但是無法給數據庫的並發操作帶來效率上的提高，因為分表的實質還是在一個數據庫上進行的操作，很容易受數據庫IO性能的限制。

因此，如何將數據庫IO性能的問題平均分配出來，很顯然將數據進行分庫操作可以很好地解決單臺數據庫的性能問題。

分庫策略與分表策略的實現很相似，最簡單的都是可以通過取模的方式進行路由。

還是上例，將用戶ID進行取模操作，這樣的話獲取到具體的某一個數據庫，同樣關鍵字有：

用戶ID、庫容量

路由的示意圖如下：

技術分享圖片

上圖中庫容量為100。

同樣，如果用戶ID為UUID請先hash然後在進行取模。

四、分庫與分表實現策略

上述的配置中，數據庫分表可以解決單表海量數據的查詢性能問題，分庫可以解決單臺數據庫的並發訪問壓力問題。

有時候，我們需要同時考慮這兩個問題，因此，我們既需要對單表進行分表操作，還需要進行分庫操作，以便同時擴展系統的並發處理能力和提升單表的查詢性能，就是我們使用到的分庫分表。

分庫分表的策略相對於前邊兩種復雜一些，一種常見的路由策略如下：

１、中間變量　＝ user_id%（庫數量*每個庫的表數量）;
２、庫序號　＝　取整（中間變量／每個庫的表數量）;
３、表序號　＝　中間變量％每個庫的表數量;
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

例如：數據庫有256 個，每一個庫中有1024個數據表，用戶的user_id＝262145，按照上述的路由策略，可得：

１、中間變量　＝ 262145%（256*1024）= 1;
２、庫序號　＝　取整（1／1024）= 0;
３、表序號　＝　1％1024 = 1;
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

這樣的話，對於user_id＝262145，將被路由到第０個數據庫的第１個表中。

示意圖如下：

技術分享圖片

五、分庫分表總結

關於分庫分表策略的選擇有很多種，上文中根據用戶ID應該是比較簡單的一種。其他方式比如使用號段進行分區或者直接使用hash進行路由等。有興趣的可以自行查找學習。

關於上文中提到的，如果用戶的ID是通過UUID的方式生成的話，我們需要單獨的進行一次hash操作，然後在進行取模操作等，其實hash本身就是一種分庫分表的策略，使用hash進行路由策略的時候，我們需要知道的是，也就是hash路由策略的優缺點，優點是：數據分布均勻；缺點是：數據遷移的時候麻煩，不能按照機器性能分攤數據。

上述的分庫和分表操作，查詢性能和並發能力都得到了提高，但是還有一些需要註意的就是，例如：原本跨表的事物變成了分布式事物；由於記錄被切分到不同的數據庫和不同的數據表中，難以進行多表關聯查詢，並且不能不指定路由字段對數據進行查詢。分庫分表之後，如果我們需要對系統進行進一步的擴陣容（路由策略變更），將變得非常不方便，需要我們重新進行數據遷移。

最後需要指出的是，分庫分表目前有很多的中間件可供選擇，最常見的是使用淘寶的中間件Cobar。

GitHub地址：https://github.com/alibaba/cobara

文檔地址為：https://github.com/alibaba/cobar/wiki

關於淘寶的中間件Cobar本篇內容不具體介紹，會在後邊的學習中在做介紹。

另外spring也可以實現數據庫的讀寫分離操作，後邊的文章，會進一步學習。

六、總結

上述中，我們學到了如何進行數據庫的讀寫分離和分庫分表，那麽，是不是可以實現一個可擴展、高性能、高並發的網站那？很顯然還不可以!一個大型的網站使用到的技術遠不止這些，可以說，這些都是其中的最基礎的一個環節，因為還有很多具體的細節我們沒有掌握到，比如：數據庫的集群控制，集群的負載均衡，災難恢復，故障自動切換，事務管理等等技術。因此，還有很多需要去學習去研究的地方。

總之：

路漫漫其修遠兮，吾將上下而求索。

參考鏈接：https://blog.csdn.net/achuo/article/details/72229236


MySQL分庫分表

相關推薦

MySQL分庫分表備份腳本

數據庫備份數據庫腳本[[email protected]/* */ script]# cat store_backup.sh #!/bin/shMYUSER=rootMYPASS=qwe123SOCKET=/data/3306/mysql.sockMYLOGIN="mysql -u$MYUSER

MySQL分庫分表方案

人員 有趣的 而不是 其他 代理 延時 分片 -o 得到 1. MySQL分庫分表方案 1.1. 問題： 1.2. 回答： 1.2.1. 最好的切分MySQL的方式就是：除非萬不得已，否則不要去幹它。 1.2.2. 你的SQL語句不再是聲明式的（declarativ

mysql 分庫分表（水平切割和垂直切割）

edi redis 就是 什麽 AR tail 創建 god 分割 分表是分散數據庫壓力的好方法。 分表，最直白的意思，就是將一個表結構分為多個表，然後，可以再同一個庫裏，也可以放到不同的庫。 當然，首先要知道什麽情況下，才需要分表。個人覺得單表記錄條數達到百萬到千萬級別時

【分庫、分表】MySQL分庫分表方案

分表 性能 正常 事先 AD 現在 新用戶 我們 java 一、Mysql分庫分表方案 1.為什麽要分表： 當一張表的數據達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小數據庫的負擔，縮短查詢時間。 mys

MySQL分庫分表

ref 點擊 ace 技術 HERE atom hash 部分 function 相關文章： 1、 使用Spring AOP實現MySQL數據庫讀寫分離案例分析 2、MySQL5.6 數據庫主從（Master/Slave）同步安裝與配置詳解 3、MySQL主從復制的常

實現MySQL分庫分表備份的腳本

linux 運維 linux運維工程師1）準備測試數據：通過寫腳本批量建庫建表並插入測試數據。[root@aliyun scripts]# cat ceshi.sh #/bin/bashPATH="/usr/local/mysql/bin:$PATH" #定

MySQL 分庫分表方案，總結的非常好！

導致 一個 磁盤空間 所有 bsp 功能 編程 從庫 框架 前言 公司最近在搞服務分離，數據切分方面的東西，因為單張包裹表的數據量實在是太大，並且還在以每天60W的量增長。 之前了解過數據庫的分庫分表，讀過幾篇博文，但就只知道個模糊概念， 而且現在回想起來什麽都是模模糊糊的

oracle遷移到mysql分庫分表方案之——ogg(goldengate)

apply columns version alt ML -c testing name sam 之前文章主要介紹了oracle 遷移到mysql，主要是原表原結構遷移，但是實際運維中會發現，到mysql以後需要分庫和分表的拆分操作，這個時候，用ogg來做，也是很強大好用的

Shell腳步之MySql分庫分表備份

前言 資料備份的重要性已經不用過多強調了。這篇文章我們就以MySQL資料進行演示如何通過Shell腳步進行MySQL資料庫的分庫分表備份。 要求 Linux命令要求比較熟悉，Shell腳步語法規則也要熟悉，MySQL的資料庫備份命令要比較熟悉。下面也會提到，如果有不懂得希望可以自行查閱資料學習。 命令

MySQL 分庫分表及其平滑擴容方案 MySQL 分庫分表及其平滑擴容方案

MySQL 分庫分表及其平滑擴容方案 <a class="follow-nickName" href="https://me.csdn.net/kefengwang" target=

Mysql分庫分表匯出匯入和資料量統計測試

需求：新增建立了分庫分表後，業務可能將資料已經寫入，但未來得及接入到otter彙總庫。接入彙總庫前需要初始化這部分資料。 1.匯出 ip_port_list=(5.5.5.101:3306 5.5.5.102:3306) len=${#ip_port_list[@]} for ((

MySQL分庫分表詳解

一 分庫分表 1 什麼是分庫分表 – 將存放在一個數據庫（主機）中的資料，按照特定方式進行拆分，分散存放到多個數據庫（主機）中，以達到分散單臺裝置負載的效果。 2 垂直分隔 1） 縱向切分（分多個表） –將單個表，拆分成多個表，分散到不同的資料庫 –將單個數據庫的多個表進行分類，按業務分

MySQL 分庫分表方案總結

1.為什麼要分表： 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。 mysql中有一種機制是表鎖定和行鎖定，是為了保證資料的完整性。表鎖定表示你們都不能對這張表進行操作，必須等我對

MySQL分庫分表面試知識總結

場景分析 Web開發工作，亦或是海量資料開發工作，學習分庫、分表、分割槽等知識都是很有必要的 。 面試的時候，也有可能也會被問到。不過作為一個有經驗的Coder，不熟悉分庫、分表技術確實有些 low

mysql分庫分表的方法

分表後怎麼做全文搜尋 1.merge方式分表(不好) 2. 使用 sql union 3 使用Sphinx全文檢索引擎 一，先說一下為什麼要分表 當一張的資料達到幾百萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫

MySQL分庫分表--全域性ID生成方案

摘要： 介紹來自flicker和twitter的兩種解決分散式環境下全域性ID生成方案。 目錄： 1. 資料庫自增ID——來自Flicker的解決方案 2. 獨立的應用程式——來自Twitter的解決方案 在大型網際網路應用中，隨著使用者數的增加，為了提高應用的效能，我們經

使用淘寶中介軟體cobar實現mysql分庫分表

cobar 編譯安裝配置筆記 https://github.com/alibaba/cobar windows下使用eclipse匯入cobar專案,eclipse File -> Import -> Git https://github.com/alibab

MyBatis+Mysql分庫分表的案例分析

**多資料來源動態切換 *分庫分表*** 參考 [AbstractRoutingDataSource動態資料來源切換，AOP實現動態資料來源切換](https://blog.csdn.net/u012881904/article/details/77449710) 案例原理：

MySQL分庫分表多維度查詢——比較好的方法

MySQL分庫分表,一般只能按照一個維度進行查詢.以訂單表為例, 按照使用者ID mod 64 分成 64個數據庫.按照使用者的維度查詢很快,因為最終的查詢落在一臺伺服器上.但是如果按照商戶的維度查詢,則代價非常高.需要查詢全部64臺伺服器.在分頁的情況下,更加惡化.比如某個商戶查詢第10頁的資料(按照訂單的

mysql分庫分表方案淺析

分庫分表(這裡不討論中介軟體)分庫：原因：單機負載高，優點：降低單機負載分表：原因：單表讀寫壓力大或者資料增長快，優點：使用多個表，提高讀寫效率 1、(程式碼)分表，即把一個很大的表達資料分到幾個表中，這樣每個表資料都不多。                  優點：提高併發