blog.csdn.net/qq_39390545/article/details/116248222

一、樸實(shí)無華的 - 分表

1、垂直分表

2、水平分表

二、花里胡哨的 - 分庫

3、垂直分庫

4、水平分庫

總結(jié)

首先我們要知道分庫、分表都是干啥的，本文主角還是我們的MySQL為第一視角。首先從字面意思來看：

分庫：由單個(gè)數(shù)據(jù)庫實(shí)例拆分成多個(gè)數(shù)據(jù)庫實(shí)例，將數(shù)據(jù)分布到多個(gè)數(shù)據(jù)庫實(shí)例中。

分表：由單張表拆分成多張表，將數(shù)據(jù)劃分到多張表內(nèi)。

要知道，對于大型互聯(lián)網(wǎng)項(xiàng)目，數(shù)據(jù)量級可能不是我們能想到的，每日新增數(shù)據(jù)量過千萬是常有的事兒，想靠單臺MySQL服務(wù)器是不現(xiàn)實(shí)的。你項(xiàng)羽在牛B，也頂不住四個(gè)隊(duì)友掛機(jī)?。?！項(xiàng)羽：？？？

隨著業(yè)務(wù)數(shù)據(jù)量和網(wǎng)站QPS日益增高，對數(shù)據(jù)庫壓力也越來越大，單機(jī)版數(shù)據(jù)庫很快會到達(dá)存儲和并發(fā)瓶頸，就需要做數(shù)據(jù)庫性能方面的優(yōu)化，分庫分表采取的是分而治之的策略，分庫目的是減輕單臺MySQL實(shí)例存儲壓力及可擴(kuò)展性，而分表是解決單張表數(shù)據(jù)過大以后查詢的瓶頸問題，坦白說，這些問題也是所有關(guān)系型數(shù)據(jù)庫的“硬傷”。

今天我們就基于常見分庫、分表的策略方式以及場景，來搞清楚我們到底啥時(shí)候用的到。常用策略包括：垂直分表、水平分表、垂直分庫、水平分庫。

一、樸實(shí)無華的 - 分表

1、垂直分表

垂直分表，或者叫豎著切表，是不是感受到該策略是以字段為依據(jù)的！主要按照字段的活躍性、字段長度，將表中字段拆分到不同的表（主表和擴(kuò)展表）中。

特點(diǎn)：

每個(gè)表的結(jié)構(gòu)都不一樣；

每個(gè)表的數(shù)據(jù)也不一樣，

有一個(gè)關(guān)聯(lián)字段，一般是主鍵或外鍵，用于關(guān)聯(lián)兄弟表數(shù)據(jù)；

所有兄弟表的并集是該表的全量數(shù)據(jù)；

場景 ：

有幾個(gè)字段屬于熱點(diǎn)字段，更新頻率很高，要把這些字段單獨(dú)切到一張表里，不然innodb行鎖很惡心的，鎖死你呀~~如用戶表里的余額字段？不，我的余額就很穩(wěn)定，一直是0。。

有大字段，如text，存儲壓力很大，畢竟innodb數(shù)據(jù)和索引是同一個(gè)文件；同時(shí)，我又喜歡用SELECT *，你懂得，這磁盤IO消耗的，跟玩兒似的，誰都扛不住的。

有明顯的業(yè)務(wù)區(qū)分，或表結(jié)構(gòu)設(shè)計(jì)時(shí)字段冗余；有些小伙伴看到第一點(diǎn)時(shí)，就發(fā)現(xiàn)陳哈哈是個(gè)菜雞，用戶表怎么會有余額字段？明顯有問題??！趕緊先到評論區(qū)噴陳哈哈一波~~然后笑嘻嘻的發(fā)現(xiàn)原來是個(gè)小尾巴，真不要臉是吧。。是的，因此不同業(yè)務(wù)我們要把具體字段拆開，這樣才有利于業(yè)務(wù)后續(xù)擴(kuò)展哦。

2、水平分表

水平分表，也叫“橫著切”。。以行數(shù)據(jù)為依據(jù)進(jìn)行切分，一般按照某列的自容進(jìn)行切分。

如手機(jī)號表，我們可以通過前兩位或前三位進(jìn)行切分，如131、132、133 → phone_131、phone_132、phone_133，手機(jī)號有11位（100億），量大是很正常的事兒，這年頭誰家老頭老太太每個(gè)手機(jī)呢是吧。這樣切就把一張大表切成了好幾十張小表，數(shù)據(jù)量不就下來了。有同學(xué)就問了那我怎么知道我這手機(jī)號查哪個(gè)表呢？一看你就沒認(rèn)真看前兩行標(biāo)紅的點(diǎn)，為啥標(biāo)紅嘞？比如我查13100001111，那我截取前三位，動態(tài)拼接到查詢的表名上，就行了。

特點(diǎn)：

每個(gè)表的結(jié)構(gòu)都一樣；

每個(gè)表的數(shù)據(jù)都不一樣，沒有交集；

所有表的并集是該表的全量數(shù)據(jù)；

場景 ：單表的數(shù)據(jù)量過大或增長速度很快，已經(jīng)影響或即將會影響SQL查詢效率，加重了CPU負(fù)擔(dān)，提前到達(dá)瓶頸。記得水平分表越早越好，別問我為什么。。

你要有興趣試一試，就關(guān)注我，讓csdn研發(fā)同學(xué)給我的粉絲們分個(gè)表哈哈。。算了，別做夢了，忘了你是個(gè)菜狗了么~

二、花里胡哨的 - 分庫

需要你注意的是，傳統(tǒng)的分庫和我們熟悉的集群、主從復(fù)制可不是一個(gè)事兒；多節(jié)點(diǎn)集群是將一個(gè)庫復(fù)制成N個(gè)庫，從而通過讀寫分離實(shí)現(xiàn)多個(gè)MySQL服務(wù)的負(fù)載均衡，實(shí)際是圍繞一個(gè)庫來搞的，這個(gè)庫稱為Master主庫。而分庫就不同了，分庫是將這個(gè)主庫一分為N，比如一分為二，然后針對這兩個(gè)主庫，再配置2N個(gè)從庫節(jié)點(diǎn)。

3、垂直分庫

縱向切庫，太經(jīng)典的切分方式，基于表進(jìn)行切分，通常是把新的業(yè)務(wù)模塊或集成公共模塊拆分出去，比如我們最熟悉的單點(diǎn)登錄、鑒權(quán)模塊。熟悉的味道，記得有一次我把一些沒用的表切到一個(gè)性能很好的服務(wù)器中，這服務(wù)器我專門用來學(xué)習(xí)，后來也不知被哪個(gè)狗腿子告密了~ 我**你個(gè)**，有種站出來，你個(gè)**東西。

特點(diǎn)：

每個(gè)庫的表都不一樣；

表不一樣，數(shù)據(jù)就更不一樣了~ 沒有任何交集；

每個(gè)庫相對獨(dú)立，模塊化

場景 ：可以抽象出單獨(dú)的業(yè)務(wù)模塊時(shí)，可以抽象出公共區(qū)時(shí)（如字典、公共時(shí)間、公共配置等），或者想有一臺屬于自己的服務(wù)器時(shí)？

4、水平分庫

以行數(shù)據(jù)為依據(jù)，將一個(gè)庫中的數(shù)據(jù)拆分到多個(gè)庫中。大型分表體驗(yàn)一下？坦白說這種策略并不實(shí)用，因?yàn)闀笈_開發(fā)很不友好，有很多坑，不建議采用，理解即可。

特點(diǎn)：

每個(gè)庫的結(jié)構(gòu)都一樣；

每個(gè)庫的數(shù)據(jù)都不一樣，沒有交集；

所有庫的并集是全量數(shù)據(jù)；

場景 ：系統(tǒng)絕對并發(fā)量上來了，CPU內(nèi)存壓力大。分表難以根本上解決量的問題，并且還沒有明顯的業(yè)務(wù)歸屬來垂直分庫，主庫磁盤接近飽和。

總結(jié)

本文就到這里，希望你學(xué)廢了！其實(shí)，在實(shí)際工作中，我們在選擇分庫分表策略前，想到的應(yīng)該是從緩存、讀寫分離、SQL優(yōu)化等方面，因?yàn)檫@些能夠更直接、代價(jià)更小的解決問題。要記住動表就是動根本，你永遠(yuǎn)不知道這張表后面會連帶多少歷史遺留問題，如果是個(gè)很大型的項(xiàng)目，遇到些問題你就跟經(jīng)理提議要分庫分表，小心被呼死~

責(zé)任編輯：haq