一.分分合合

說過很多次，不要拘泥于某一個技術(shù)的一點，技術(shù)是相通的。重要的是編程思想，思想是最重要的。

當(dāng)數(shù)據(jù)量大的時候，需要具有分的思想去細(xì)化粒度。當(dāng)數(shù)據(jù)量太碎片的時候，需要具有合的思想來粗化粒度。

1.1 分

很多技術(shù)都運用了分的編程思想，這里來舉幾個例子，這些都是分的思想

• 集中式服務(wù)發(fā)展到分布式服務(wù)

• 從Collections.synchronizedMap(x)到1.7ConcurrentHashMap再到1.8ConcurrentHashMap，細(xì)化鎖的粒度的同時依舊保證線程安全

• 從AtomicInteger到LongAdder，ConcurrentHashMap的size()方法。用分散思想，減少cas次數(shù)，增強(qiáng)多線程對一個數(shù)的累加

• JVM的G1 GC算法，將堆分成很多Region來進(jìn)行內(nèi)存管理

• Hbase的RegionServer中，將數(shù)據(jù)分成多個Region進(jìn)行管理

• 平時開發(fā)是不是線程池都資源隔離

2.2 合

很多技術(shù)也運用到了合的編程思想，這里舉幾個例子，這些都是合的思想

• TLAB（Thread Local Allocation Buffers），線程本地分配緩存。避免多線程沖突，提高對象分配效率

• 逃逸分析，將變量的實例化內(nèi)存直接在棧里分配，無需進(jìn)入堆，線程結(jié)束棧空間被回收。減少臨時對象在堆內(nèi)分配數(shù)量

• CMS GC算法下，雖然使用標(biāo)記清除，但是也有配置支持整理內(nèi)存碎片。如：-XX:UseCMS-CompactAtFullCollection（FullGC后是否整理，Stop The World會變長）和-XX:CMSFullGCs-BeforeCompaction（幾次FullGC之后進(jìn)行壓縮整理）

• 鎖粗化，當(dāng)JIT發(fā)現(xiàn)一系列連續(xù)的操作都是對同一對象反復(fù)加鎖和釋放鎖，會加大鎖同步的范圍

• kafka的網(wǎng)絡(luò)數(shù)據(jù)傳輸有一些數(shù)據(jù)配置，減少網(wǎng)絡(luò)開銷。如：batch.size和linger.ms等等

• 平時開發(fā)是不是都個叫批量獲取接口

二.分區(qū)

本文一切基于MySql InnoDB

說了這么多，接下來說主體，先說分區(qū)，因為之前博主寫過一篇MySql分區(qū)的博客所以這里不會多費筆墨來寫

2.1 實現(xiàn)方式

具體如何實現(xiàn)上面鏈接里有寫，這里只需記住如果表中存在主鍵或唯一索引時，分區(qū)列必須是唯一索引的一個組成部分。

這個是數(shù)據(jù)庫分的，應(yīng)用透明，代碼無需修改任何東西。

2.2 內(nèi)部文件

先去data目錄，如果不知道目錄位置的可以執(zhí)行：

接下來看下內(nèi)部文件：

?

從上圖我們可以看出，有2中類型的文件，.frm文件和.ibd文件

• .frm文件：表結(jié)構(gòu)文件

• .ibd文件：InnoDB中，索引和數(shù)據(jù)都在同個文件.ibdata（你的執(zhí)行結(jié)果可能是.MYD索引文件和.MYI數(shù)據(jù)文件，沒關(guān)系，這是MyIsAm存儲引擎，對應(yīng)著InnoDB的.ibd文件）。因為Order這張表分為5個區(qū)，所以有5個這樣的文件

• .par文件：你執(zhí)行的結(jié)果可能有.par文件也可能沒有。注意：從MySql 5.7.6開始，不再創(chuàng)建.par分區(qū)定義文件。分區(qū)定義存儲在內(nèi)部數(shù)據(jù)字典中。

2.3 數(shù)據(jù)處理

分區(qū)表后，提高了MySql性能。如果一張表的話，那就只有一個.ibd文件，一顆大的B+樹。如果分表后，將按分區(qū)規(guī)則，分成不同的區(qū)，也就是一個大的B+樹，分成多個小的樹。

讀的效率肯定提升了，如果走分區(qū)鍵索引的話，先走對應(yīng)分區(qū)的輔助索引B+樹，再走對應(yīng)分區(qū)的聚集索引B+樹。

如果沒有走分區(qū)鍵，將會在所有分區(qū)都會執(zhí)行一次。會造成多次邏輯IO！

平時開發(fā)如果想查看sql語句的分區(qū)查詢可以使用explain partitons select xxxxx語句。可以看到一句select語句走了幾個分區(qū)。

mysql>?explain?partitions?select?*?from?TxnList?where?startTime>'2016-08-25?00:00:00'?and?startTime<'2016-08-25?23:59:00';?? +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+?? |?id?|?select_type?|?table?????????????|?partitions?|?type?|?possible_keys?|?key??|?key_len?|?ref??|?rows??|?Extra???????|?? +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+?? |??1?|?SIMPLE??????|?ClientActionTrack?|?p20160825??|?ALL??|?NULL??????????|?NULL?|?NULL????|?NULL?|?33868?|?Using?where?|?? +----+-------------+-------------------+------------+------+---------------+------+---------+------+-------+-------------+?? row?in?set?(0.00?sec)

三.分庫分表

當(dāng)一張表隨著時間和業(yè)務(wù)的發(fā)展，庫里表的數(shù)據(jù)量會越來越大。數(shù)據(jù)操作也隨之會越來越大。

一臺物理機(jī)的資源有限，最終能承載的數(shù)據(jù)量、數(shù)據(jù)的處理能力都會受到限制。這時候就會使用分庫分表來承接超大規(guī)模的表，單機(jī)放不下的那種。

區(qū)別于分區(qū)的是，分區(qū)一般都是放在單機(jī)里的，用的比較多的是時間范圍分區(qū)，方便歸檔。只不過分庫分表需要代碼實現(xiàn)，分區(qū)則是mysql內(nèi)部實現(xiàn)。分庫分表和分區(qū)并不沖突，可以結(jié)合使用。

3.1 實現(xiàn)

3.1.1 分庫分表標(biāo)準(zhǔn)

• 存儲占用100G+

• 數(shù)據(jù)增量每天200w+

• 單表條數(shù)1億條+

3.1.2 分庫分表字段

分庫分表字段取值非常重要

在大多數(shù)場景該字段是查詢字段

數(shù)值型

一般使用userId，可以滿足上述條件

3.2 分布式數(shù)據(jù)庫中間件

分布式數(shù)據(jù)庫中間件分為兩種，proxy和客戶端式架構(gòu)。proxy模式有MyCat、DBProxy等，客戶端式架構(gòu)有TDDL、Sharding-JDBC等。

那么proxy和客戶端式架構(gòu)有何區(qū)別呢？各自有什么優(yōu)缺點呢？其實看一張圖便可知曉。

proxy模式的話我們的select和update語句都是發(fā)送給代理，由這個代理來操作具體的底層數(shù)據(jù)庫。所以必須要求代理本身需要保證高可用，否則數(shù)據(jù)庫沒有宕機(jī)，proxy掛了，那就走遠(yuǎn)了。

客戶端模式通常在連接池上做了一層封裝，內(nèi)部與不同的庫連接，sql交給smart-client進(jìn)行處理。通常僅支持一種語言，如果其他語言要使用，需要開發(fā)多語言客戶端。

各自的優(yōu)缺點如下：?

3.3 內(nèi)部文件

找了一個分庫分表+分區(qū)的例子，基本上和分區(qū)表的差不多，只是多了多了很多表的.ibd文件，上面有文件的解釋：

[miaojiaxing@Grim?testmydata]#?ls?|?grep?'base_info' base_info_00.frm base_info_00#P#p_2018.ibd base_info_00#P#p_2019.ibd base_info_00#P#p_2020.ibd base_info_00#P#p_2021.ibd base_info_00#P#p_init.ibd base_info_00#P#p_max.ibd base_info_01.frm base_info_01#P#p_2018.ibd base_info_01#P#p_2019.ibd base_info_01#P#p_2020.ibd base_info_01#P#p_2021.ibd base_info_01#P#p_init.ibd base_info_01#P#p_max.ibd base_info.frm base_info.ibd

3.4 問題

3.4.1 事務(wù)問題

既然分庫分表了，那么肯定涉及到分布式事務(wù)，如何保證插入到不同庫的多條記錄能夠要么同時成功，要么同時失敗。

有些同學(xué)可能想到XA，XA性能差而且不需要使用mysql5.7。柔性事務(wù)是目前主流的方案，TCC模式就屬于柔性事務(wù)。

對于分布式事務(wù)問題每家公司有自己的實現(xiàn)，華為用saga，阿里用TXC，螞蟻用DTX，支持FMT模式和TCC模式。

3.4.2 join問題

tddl、MyCAT等都支持跨分片join。但是盡力避免跨庫join，比如通過字段冗余的方式等。

如果出現(xiàn)了這種情況且中間件支持分片join，那么可以這樣使用。如果不支持可以手工查詢。

四.總結(jié)

分表和在用途上不一樣，分表是為了承接超大規(guī)模的表，單機(jī)放不下那種。分區(qū)的話則一般都是放在單機(jī)里的，用的比較多的是時間范圍分區(qū)，方便歸檔。

性能穩(wěn)定上的話都是一個個子表，差不多，區(qū)別應(yīng)該是分區(qū)表是mysql內(nèi)部實現(xiàn)的，會比分表方案少一點數(shù)據(jù)交互。

作者：GrimMjx

鏈接：www.cnblogs.com/GrimMjx/p/11772033.html

END 最后說個題外話，相信大家都知道視頻號了，隨著灰度范圍擴(kuò)大，越來越多的小伙伴都開通了視頻號。小詹也開通了一個視頻號，會分享互聯(lián)網(wǎng)那些事、讀書心得與副業(yè)經(jīng)驗，歡迎掃碼關(guān)注，和小詹一起向上生長！「沒有開通發(fā)布權(quán)限的盡量多互動，提升活躍度可以更快開通哦」（聽我一分鐘，生活更輕松）（掃碼回復(fù) 1024 即可領(lǐng)取IT資料包） 與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的彻底搞清楚MySQL分库、分表、分区的区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。