老大讓我優(yōu)化數(shù)據(jù)庫(kù)，我上來(lái)就分庫(kù)分表，他過(guò)來(lái)就是一jio。。。

來(lái)自：CSDN，作者：_陳哈哈

鏈接：https://blog.csdn.net/qq_39390545/article/details/116248222

• 一、樸實(shí)無(wú)華的 - 分表
• 1、垂直分表
• 2、水平分表
• 二、花里胡哨的 - 分庫(kù)
• 3、垂直分庫(kù)
• 4、水平分庫(kù)
• 總結(jié)

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

• 分庫(kù)：由單個(gè)數(shù)據(jù)庫(kù)實(shí)例拆分成多個(gè)數(shù)據(jù)庫(kù)實(shí)例，將數(shù)據(jù)分布到多個(gè)數(shù)據(jù)庫(kù)實(shí)例中。
• 分表：由單張表拆分成多張表，將數(shù)據(jù)劃分到多張表內(nèi)。

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

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

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

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

1、垂直分表

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

特點(diǎn)：

• 每個(gè)表的結(jié)構(gòu)都不一樣；
• 每個(gè)表的數(shù)據(jù)也不一樣，
• 有一個(gè)關(guān)聯(lián)字段，一般是主鍵或外鍵，用于關(guān)聯(lián)兄弟表數(shù)據(jù)；
• 所有兄弟表的并集是該表的全量數(shù)據(jù)；

場(chǎng)景?：

1. 有幾個(gè)字段屬于熱點(diǎn)字段，更新頻率很高，要把這些字段單獨(dú)切到一張表里，不然innodb行鎖很惡心的，鎖死你呀~~如用戶(hù)表里的余額字段？不，我的余額就很穩(wěn)定，一直是0。。
2. 有大字段，如text，存儲(chǔ)壓力很大，畢竟innodb數(shù)據(jù)和索引是同一個(gè)文件；同時(shí)，我又喜歡用SELECT *，你懂得，這磁盤(pán)IO消耗的，跟玩兒似的，誰(shuí)都扛不住的。
3. 有明顯的業(yè)務(wù)區(qū)分，或表結(jié)構(gòu)設(shè)計(jì)時(shí)字段冗余；有些小伙伴看到第一點(diǎn)時(shí)，就發(fā)現(xiàn)陳哈哈是個(gè)菜雞，用戶(hù)表怎么會(huì)有余額字段？明顯有問(wèn)題??！趕緊先到評(píng)論區(qū)噴陳哈哈一波~~然后笑嘻嘻的發(fā)現(xiàn)原來(lái)是個(gè)小尾巴，真不要臉是吧。。是的，因此不同業(yè)務(wù)我們要把具體字段拆開(kāi)，這樣才有利于業(yè)務(wù)后續(xù)擴(kuò)展哦。

2、水平分表

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

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

特點(diǎn)：

• 每個(gè)表的結(jié)構(gòu)都一樣；
• 每個(gè)表的數(shù)據(jù)都不一樣，沒(méi)有交集；
• 所有表的并集是該表的全量數(shù)據(jù)；

場(chǎng)景?：?jiǎn)伪淼臄?shù)據(jù)量過(guò)大或增長(zhǎng)速度很快，已經(jīng)影響或即將會(huì)影響SQL查詢(xún)效率，加重了CPU負(fù)擔(dān)，提前到達(dá)瓶頸。記得水平分表越早越好，別問(wèn)我為什么。。

二、花里胡哨的 - 分庫(kù)

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

3、垂直分庫(kù)

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

特點(diǎn)：

• 每個(gè)庫(kù)的表都不一樣；
• 表不一樣，數(shù)據(jù)就更不一樣了~ 沒(méi)有任何交集；
• 每個(gè)庫(kù)相對(duì)獨(dú)立，模塊化

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

4、水平分庫(kù)

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

特點(diǎn)：

• 每個(gè)庫(kù)的結(jié)構(gòu)都一樣；
• 每個(gè)庫(kù)的數(shù)據(jù)都不一樣，沒(méi)有交集；
• 所有庫(kù)的并集是全量數(shù)據(jù)；

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

總結(jié)

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