地址：https://cloud.tencent.com/developer/article/1526776

前兩篇文章重點講到了Mysql數(shù)據(jù)庫的主從同步和讀寫分離，使用主從同步實現(xiàn)從數(shù)據(jù)庫從主數(shù)據(jù)同步數(shù)據(jù)保持主從數(shù)據(jù)一致性，讀寫分離使用主數(shù)據(jù)庫負責寫操作，多個從數(shù)據(jù)庫負責讀操作，由于從庫可以進行拓展，所以處理更多的讀請求也沒問題。但是如果業(yè)務比較多，寫請求越來越多要如何處理呢？可能有人說我可以再加一個master分擔寫操作，但是兩個master數(shù)據(jù)肯定是需要同步的，主主同步 + 主從同步很顯然會讓我們的系統(tǒng)架構變得更為的復雜。所以本篇文章主要討論一個對寫操作進行切分的技術：分庫分表。

我們都知道，在業(yè)務量不多的時候，單庫單表完全可以支持我們的應用。但是隨著業(yè)務的逐漸發(fā)展，如果使用單庫單表是存在幾個弊端的：

• 隨著數(shù)據(jù)量的增大，數(shù)據(jù)庫性能會有所下降。一般來說單表合適存放1000w條數(shù)據(jù)以下。

• 如果寫請求居多，使用單臺master會導致所有寫請求都訪問該服務，肯定會導致master性能大幅度下降。

• 如果所有表全部存放在同一個數(shù)據(jù)庫，在高并發(fā)的情況下所有業(yè)務都連接同一個數(shù)據(jù)庫，由于連接的數(shù)量稀少會導致并發(fā)的上限。

而分庫分表的方式一般有兩種：垂直拆分和水平拆分。接下來我們可以分別看看這兩種分庫分表方式：

垂直拆分

垂直拆分主要有兩種：垂直分庫和垂直分表。

垂直分庫：

垂直分庫其實邏輯上會更容易理解，比如目前我數(shù)據(jù)庫有用戶相關的表如用戶表，積分表，實名認證表，還有訂單相關的比如商品表，拼團表，還有商品相關的商品表。如果全部表全部放在同一個數(shù)據(jù)庫，由于數(shù)據(jù)庫連接的匱乏以及磁盤IO等影響，所以性能肯定會收到一定的影響。這時候我們可以可以將用戶相關的放在user數(shù)據(jù)庫，商品相關的放在goods數(shù)據(jù)庫，訂單相關的放在order數(shù)據(jù)庫。然后不同的數(shù)據(jù)庫存放在不同的服務器上，這樣還可以避免因為用戶量越來越多導致數(shù)據(jù)庫性能受到服務器瓶頸的影響。所以說分庫實際上就是在多個服務器搭建多個不同的數(shù)據(jù)庫，然后按照不同的業(yè)務邏輯將不同的表存放在不同的數(shù)據(jù)庫。

垂直分表：

垂直分表主要是表中數(shù)據(jù)列成百上千的數(shù)據(jù)表使用的，使用的方案是創(chuàng)建輔助表，將表中數(shù)據(jù)量較大或者不常用的數(shù)據(jù)庫移動到輔助表，常用的字段留在原表中，這樣就可以避免我們在查詢大表的時候由于不常用的大字段影響查詢的性能。

水平拆分

水平拆分也有兩種：水平分表和水平分庫分表。

水平分表：

水平分表和垂直分表區(qū)別在于垂直分表針對的是列，將不常用的列拆分到輔助表。而水平分表針對的是表，在同一個數(shù)據(jù)庫中創(chuàng)建多張一樣的表，比如我們在order數(shù)據(jù)庫中創(chuàng)建三張訂單表order1，order2，order3，然后插入訂單時將id對3取余，根據(jù)不同的值存入不同的訂單表，但是由于水平分表是將數(shù)據(jù)表存放在同一個數(shù)據(jù)庫，水平分表可以降低單標的數(shù)據(jù)量，有助于提高查詢效率。如果業(yè)務量很大一樣會受到服務器IO的瓶頸，所以我們一般更經(jīng)常使用的還是水平分庫分表。

水平分庫分表：

水平分庫分表實際上就是在多臺不同的機器分別創(chuàng)建數(shù)據(jù)庫和數(shù)據(jù)表，比如訂單表我們可以在三臺不同的機器上分別創(chuàng)建order數(shù)據(jù)庫和order數(shù)據(jù)表，然后根據(jù)一定的邏輯將不同的數(shù)據(jù)存放到不同機器的數(shù)據(jù)庫中。一般來說水平分庫分表主要有以下幾種拆分規(guī)則：

• 范圍拆分：比如訂單表通過id拆分，id在1到100000在服務器a的order數(shù)據(jù)庫，id在100001到200000存放在服務器b的order數(shù)據(jù)庫，以此類推。

• 地理拆分：將訂單表按照不同地區(qū)將表中的數(shù)據(jù)拆分到不同服務器的order數(shù)據(jù)庫中存儲。比如可以按照省份來進行拆分。

• 取模拆分：取模就是剛才水平分表講到的比如有三個訂單表，可以將id對3取余，但是區(qū)別在于水平分庫分表是將同樣的數(shù)據(jù)庫和數(shù)據(jù)表存放在不同機器，所以說可以有效緩解單機瓶頸問題。

• 時間拆分：根據(jù)時間來拆分表中的數(shù)據(jù)，可以將表中創(chuàng)建時間超過一年的數(shù)據(jù)拆分到其他數(shù)據(jù)庫的order數(shù)據(jù)庫存儲，原表中只保留被查詢概率較高的數(shù)據(jù)，而這部分數(shù)據(jù)往往都是近期才創(chuàng)建的，所以可以通過時間拆分實現(xiàn)冷熱數(shù)據(jù)分離。

分區(qū)

分區(qū)是什么意思呢？分區(qū)實際上是指同一個數(shù)據(jù)表中不同行的數(shù)據(jù)記錄到不同的分區(qū)中，每個分區(qū)都有一個.idb文件，所以說分區(qū)可以幫助我們將一個數(shù)據(jù)表拆分成幾個更小的部分。Mysql只支持局部索引分區(qū)不支持全局分區(qū)，mysql每一個分區(qū)既保存了數(shù)據(jù)，又存放了索引。MySQL分區(qū)主要分為以下幾種：

• RANGE分區(qū)：RANGE分區(qū)主要用于日期列的分區(qū)，是基于連續(xù)區(qū)間的列值來進行分區(qū)的。RANGE分區(qū)也是最常用的分區(qū)方式。

• LIST分區(qū)：LIST分區(qū)列的值是散列的，也正是由于分區(qū)列的值是散列的所以需要手動定義分區(qū)列的值。

• HASH分區(qū)：HASH分區(qū)就是通過自定義算法將數(shù)據(jù)均勻分布到不同分區(qū)，保證所有分區(qū)中數(shù)據(jù)大致相同。HASH分區(qū)只支持整數(shù)分區(qū)。

• KEY分區(qū)：key分區(qū)使用數(shù)據(jù)庫自帶函數(shù)進行分區(qū)。KEY分區(qū)可支持BLOB和TEXT列之外的數(shù)據(jù)列分區(qū)。

分區(qū)注意點

分區(qū)主要注意一點，如果要分區(qū)的表有主鍵或唯一鍵，則分區(qū)表的主鍵/唯一鍵必須包含分區(qū)鍵。分區(qū)的意義在于將一張大表根據(jù)分區(qū)條件分割成幾個小表，但是對于數(shù)據(jù)來說仍然是一張表，可以改善大表的可伸縮性，可管理性，還可以提高數(shù)據(jù)庫的效率。

分區(qū)的優(yōu)點

• 與數(shù)據(jù)存放在單個磁盤相比，可以存儲更多的數(shù)據(jù)。

• 對于那些已經(jīng)失效的數(shù)據(jù)，通?？梢酝ㄟ^刪除對應的分區(qū)，來實現(xiàn)刪除數(shù)據(jù)，這樣比delete效率更高。

• 一些查詢可以得到極大的優(yōu)化，滿足一個給定WHERE語句的數(shù)據(jù)可以只保存在一個分區(qū)內(nèi)，這樣在查找時就不用查找其他剩余的分區(qū)。

• 涉及聚合函數(shù)的查詢，可以進行并行處理。意味著聚合函數(shù)查詢可以在每個分區(qū)上同時進行，最終結果只需通過總計所有分區(qū)得到的結果。

分庫分表產(chǎn)生的問題

分庫分表可以一定程度去除數(shù)據(jù)庫的瓶頸，但是不可避免的分庫分表會帶來一部分問題，分庫分表主要有兩個問題：聯(lián)表查詢join操作困難和分布式事務的問題。

聯(lián)表查詢

我們一開始單庫多表的情況下使用join聯(lián)表操作是非常簡單的，使用一條簡單的sql語句配上join就可以得到我們需要的結果，但是分庫之后我們可能一次查詢無法完成，我們可能需要先去服務器a查詢用戶信息，再去服務器b, c, d分別查詢訂單信息才能完成我們的聯(lián)表查詢功能，聯(lián)表查詢功能我覺得比較適合的一個邏輯是分別查詢出我們需要的數(shù)據(jù)，然后代碼方面在service層負責組裝所有數(shù)據(jù)，最后再返還給客戶端，這樣雖然比較復雜，但是數(shù)據(jù)庫的性能可以得到最大化。

分布式事務

進行分庫操作之后，事務操作就變成分布式事務了，而之前在談Redis的時候特提到過分布式，我們都知道涉及到分布式邏輯都是比較復雜的，而且如果使用Mysql自帶的分布式事務管理功能會導致性能大大降低，大概是單庫的一成左右性能，所以方案一般有兩種：使用分布式事務中間件比如Mycat或者在代碼中業(yè)務邏輯進行控制，不過如果在代碼中控制，可能會使系統(tǒng)更加復雜，可維護性比較低。

本文分享自微信公眾號 -?程序猿周先森（zhanyue_org）

原文出處及轉載信息見文內(nèi)詳細說明，如有侵權，請聯(lián)系?yunjia_community@tencent.com?刪除。

原始發(fā)表時間：2019-10-21

本文參與騰訊云自媒體分享計劃，歡迎正在閱讀的你也加入，一起分享。

發(fā)表于?2019-10-24