?

?筆者覺得，分庫分表確實好的。但是，動不動搞分庫分表，太麻煩了。分庫分表雖然是提高數據庫性能的常規辦法，但是太麻煩了。所以，嘗試研究mysql的分區到底如何。

?之前寫過一篇文章，http://www.cnblogs.com/wangtao_20/p/7115962.html 討論過訂單表的分庫分表，折騰起來工作量挺大的，需要多少技術去折騰。做過的人才知道有多麻煩

?

? ?要按照什么字段切分，切分數據后，要遷移數據;分庫分表后，會涉及到跨庫、跨表查詢，為了解決查詢問題，又得用其他方案來彌補(比如為了應對查詢得做用戶訂單關系索引表)。工作量確實不小。

?

? 從網上也可以看到，大部分實施過的人(成功的)的經驗總結：水平分表，不是必須的，能不做，盡量不做。

?

像阿里這些系統，數據庫單表數量十多億，達到瓶頸了，不得不做分庫分表，擴容也方便。沒有選擇。 那么，針對起步階段的業務，技術人員不夠，產品還處在試錯階段。是不是可以考慮一下分區方案。 筆者幾年前，也犯了思維錯誤，在小公司做系統，產品還在開發，有待推向市場驗證。那個時候，筆者就去考慮什么評論表數據量大的情況下要怎么做，其實傷腦，又費時間，業務沒有做起來，其實沒多少用處。 架構是演變出來的，不是設計出來的。企圖一開始就設計大炮，結果只有蚊子。筆者做試驗看看mysql的分區到底是什么個原理。研究發現，其實跟分表差不多，比如按hash打散數據、按值范圍分散數據。

? ?

?一、探討分區的原理

?

了解分區到底在做什么，存儲的數據文件有什么變化，這樣知道分區是怎么提高性能的。

?

實際上：每個分區都有自己獨立的數據、索引文件的存放目錄。本質上，一個分區，實際上對應的是一個磁盤文件。所以分區越多，文件數越多。

?

現在使用innodb存儲較多，mysql默認的存儲引擎從mysiam變為了innodb了。

?

以innodb來討論：

innodb存儲引擎一張表，對應兩個文件：表名.ibd、表名.frm。

如果分區后，一個分區就單獨一個ibd文件，如下圖：

將fs_punch_in_log表拆分成4個分區，上圖中看到，每個分區就變成一個單獨的數據文件了。mysql會使用"#p#p1"來命名數據文件，1是分區的編號。總共4個分區，最大值是4。

分表的原理，實際上類似，一個表對應一個數據文件。分表后，數據分散到多個文件去了。性能就提高了。

?

分區后的查詢語句

?

語句還是按照原來的使用。但為了提高性能。還是盡量避免跨越多個分區匹配數據。

?

如下圖，由于表是按照id字段分區的。數據分散在多個分區。現在使用user_id作為條件去查詢。mysql不知道到底分配在哪個分區。所以要去全部分區掃描，如果每個分區的數據量大，這樣就耗時很長了。

?

?

?

?

?

分區思路和分區語句

?

?

id字段的值范圍來分區：在1-2千萬分到p0分區，4千萬到-6千萬p1分區。6千萬到8千萬p2分區。依此推算下去。這樣可以分成很多的分區了。

為了保持線性擴容方便。那么只能使用range范圍來算了。

?

sql如下

CREATE TABLE `fs_punch_in_log` ( `id` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主鍵自增' , `user_id` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '簽到的用戶id' , `punch_in_time` int(10) UNSIGNED NULL DEFAULT NULL COMMENT '打卡簽到時間戳' , PRIMARY KEY (`id`) )

partition BY RANGE (id) ( PARTITION p1 VALUES LESS THAN (40000000),
PARTITION p2? VALUES LESS THAN (80000000),?
PARTITION p3? VALUES LESS THAN (120000000),
PARTITION p4? VALUES LESS THAN MAXVALUE );

　　以上語句經過筆者測驗，注意點：

• ? ? ? ?按照hash均勻分散。傳遞給分區的hash()函數的值，必須是一個整數(hash計算整數計算，實現均勻分布）。上面的id字段就是表的主鍵，滿足整數要求。
• ? ? ? ?partition BY RANGE 中的partition BY表示按什么方式分區。RANGE告訴mysql，我使用范圍分區。

?

?

?

情況：如果表結構已經定義好了，里面有數據了，怎么進行分區呢？使用alter語句修改即可，經過筆者測驗了。

?

ALTER TABLE `fs_punch_in_log` PARTITION BY RANGE (id) (PARTITION p1 VALUES LESS THAN (40000000), PARTITION p2 VALUES LESS THAN (80000000), PARTITION p3 VALUES LESS THAN (120000000), PARTITION p4 VALUES LESS THAN MAXVALUE)

　　

注：由于表里面已經存在數據了，進行重新分區，mysql會把數據按照分區規則重新移動一次，生成新的文件。如果數據量比較大，耗時間比較長。

?

?

?

二、四種分區類型

?

mysql分區包括四種分區方式：hash分區、按range分區、按key分區、list分區。

四種有點多，實際上，為了好記，把類再縮小點，就兩大類方式進行分區：一種是計算hash值、一種是按照范圍值。

其實分庫分表的時候，也會用到兩大類，hash運算分、按值范圍分。

?

?1、HASH分區

?

有常規hash和線性hash兩種方式。

?

?

• 常規hash是基于分區個數取模（%）運算。根據余數插入到指定的分區。打算分4個分區，根據id字段來分區。

? ? ? ? ? ? ?怎么算出新插入一行數據，需要放到分區1，還是分區4呢? ?id的值除以4，余下1，這一行數據就分到1分區。

?

? ? ? ? ? ??常規hash，可以讓數據非常平均的分布每一個分區。比如分為4個取，取余數，余數總是0-3之間的值(總到這幾個分區去)。分配打散比較均勻。

?

? ? ? ? ? ? 但是也是有缺點的：由于分區的規則在創建表的時候已經固定了，數據就已經打散到各個分區。現在如果需要新增分區、減少分區，運算規則變化了，原來已經入庫的數據，就需要適應新的運算規則來做遷移。

? ? ? ? ? ? 實際上在分庫分表的時候，使用hash方式，也是數據量遷移的問題。不過還好。

? ? ? ? ? ? 針對這個情況，增加了線性hash的方式。

?

• 線性HASH(LINEAR HASH)稍微不同點。

? ? ? ? ?實際上線性hash算法，就是我們memcache接觸到的那種一致性hash算法。使用虛擬節點的方式，解決了上面hash方式分區時，當新增加分區后，涉及到的數據需要大量遷移的問題。也不是不需要遷移，而是需要遷移的數據量小。

?

? ? ? ? ?在技術實現上：線性哈希功能使用的一個線性的2的冪（powers-of-two）運算法則，而常規哈希使用的是求哈希函數值的模數。

?

? ? ? ? ? ?線性哈希分區和常規哈希分區在語法上的唯一區別在于，在“PARTITION BY”子句中添加“LINEAR”關鍵字。

?

?

兩者也有有相同的地方：

?

• ? ?都是均勻分布的，預先指定n個分區，然后均勻網幾個分區上面分布數據。根據一個字段值取hash值，這樣得到的結果是一個均勻分布的值。后面添加新的分區多少需要考慮數據遷移。?

?

• ? ?常規HASH和線性HASH，因為都是計算整數取余的方式，那么增加和收縮分區后，原來的數據會根據現有的分區數量重新分布。

?

• ? ? HASH分區不能刪除分區，所以不能使用DROP PARTITION操作進行分區刪除操作；

?

考慮以后遷移數據量少，使用線性hash。

?

?

?

2、按照range范圍分區

?

范圍分區，可以自由指定范圍。比如指定1-2000是一個分區，2000到5000千又是一個分區。范圍完全可以自己定。后面我要添加新的分區，很容易嗎?

?

?

?

3、按key分區

?

? ?類似于按HASH分區，區別在于KEY分區只支持計算一列或多列，且MySQL服務器提供其自身的哈希函數。必須有一列或多列包含整數值。

?

4、按list方式分區

?

可以把list看成是在range方式的基礎上的改進版。list和range本質都是基于范圍，自己控制范圍。

range是列出范圍，比如1-2000范圍算一個分區，這樣是一個連續的值。

而list分區方式是枚舉方式。可以指定在1,5,8,9,20這些值都分在第一個分區。從list單詞的字面意思命名暗示就是列表，指定列表中出現的值都分配在第幾個分區。

?

?

三、如何根據業務選擇分區類型

?

1、何時選擇分區,何時選擇分表

?

分表還是比分區更加靈活。在代碼中可以自己控制。一般分表會與分庫結合起來使用的。在進行分表的時候，順帶連分庫方案也一起搞定了。

分表分庫，性能和并發能力要比分區要強。分表后，有個麻煩點：自己需要修改代碼去不同的表操作數據。

比如用戶表分表后，計劃分4個表，每個表4千萬用戶。按照用戶編號取模為4。

代碼很多處要做專門的匹配如下：
? ? ?每次操作用戶資料，先要根據uid算出是哪個表名稱。然后再去寫sql查詢。 當然，是可以使用數據庫中間件來做完成分庫、分表。應用代碼不用修改。大部分中間件是根據他們自己的業務特點定制的，拿來使用，不見得適合自己的業務。所以目前缺少通用的。
? ? ?如果使用分區的方式。代碼不用修改。sql還是按照原來的方式寫。mysql內部自動做了匹配了。

? ? ?非常適合業務剛剛起步的時候，能不能做起來，存活期是多久不知。不用把太多精力花費在分庫分表的適應上。 考慮到現在業務才起步，使用分區不失為一種既省事又能提高數據庫并發能力的辦法。等以后業務發展起來了，數據量過億了，那個時候經濟實力已增強，再做改進方案不遲。 架構是演變出來的，不是設計出來的。適應當前業務的方案，就是好的方案。 過度設計也是一種負擔：很多技術，企圖一開始就設計出一個多大量的系統，實際上沒有那種量，為了顯示自己技術牛逼。 總結：訪問量不大，但是數據表行數很多。可以使用分區的方式。訪問量大，數據量大，可以重構成分表的方式。
? ? 這是因為雖然數據量多，但是訪問量不大，如果使用分表的話，要修改代碼很多地方，弄起來太麻煩了。投入多，產出少就沒必要了。

2、如何選擇適合自己的分區類型 使用分區和分表一樣的思想：盡量讓數據均勻分散，這樣達到分流、壓力減小的效果。如果不能均勻分布，某個分區的操作量特別大，出現單點瓶頸。 雖然4種類型的分區方式。其實總共兩大類，按范圍分區和按hash運算分區。 range范圍分區，適合按照范圍來切分數據。比如按時間范圍分區。 hash，適合均勻分散數據。使用hash分區，麻煩點是后續增加分區，數據要遷移。有了線性hash分區法，這個遷移量減低了很多。 以用戶表為例子，如果要使用分區方案。改使用哪種分區類型呢？
? ? 考慮到user_id一般不會設計成自增數字。有人會奇怪，怎么不是自增的，我見過好多用戶編號都是自增的！ 的確，有自增數字做uid的，不過一般是開源系統為了省事，比如discuz、ecshop等。人家沒那么多工作量給你設計用戶編號方案。 自增的用戶編號，由于是每次加1進行遞增的。這規律太明顯了，很容易被別有用途的人猜測user_id。再說，別人一看就知道你有多少用戶!? 有個原則，設計編號的時候，盡量不要讓外部知道你的生成規律。比如訂單號，如果是逐個加1的訂單號，外界可以猜測出你的業務訂單總數出來。 說一個自增用戶編號的例子。筆者曾經在一家上市互聯網公司，有幾千萬的用戶，uid過去是discuz那一套自增的方式。后來不得不改掉user_id的生成方式。筆者當時負責了這個改造方案。 ? ? 不是自增的數字，會是這種：注冊一個是1897996，再注冊一個是9689898，外界完全找不到數字的規律。 不是自增的編號，如果使用范圍來分區，各個分區的數據做不到均勻分布的。原因如下： 比如說用戶編號為1-200000000的用戶分配到p1分區，20000000-40000000分配到p2分區，40000000-60000000分配到p3區，這樣類推下去。 由于用戶編號不是自增，注冊分配到的用戶編號，可能是1到2千萬之間的數字，也可能是4千萬到6千萬之間的一個數字。如果被分配到4千萬到6千萬的數字會更多，那么各個分區給到的數據是不均勻的。 故不好使用范圍來分區。 比較好的辦法是，使用hash取模，user_id%分區數。數據就可以分散均勻到4個分區去了。

? ?

?

轉載于:https://www.cnblogs.com/wangtao_20/p/7119469.html

總結

以上是生活随笔為你收集整理的mysql分区方案的研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。