開(kāi)源、高性能、生態(tài)成熟的 MySQL 是國(guó)內(nèi)應(yīng)用最廣泛的數(shù)據(jù)庫(kù)，說(shuō) MySQL 見(jiàn)證了中國(guó)互聯(lián)網(wǎng)的成長(zhǎng)史，一點(diǎn)也不為過(guò)。

阿里基于 MySQL 構(gòu)建了OceanBase;京東、騰訊時(shí)至今日也在大規(guī)模應(yīng)用 MySQL。因此，它也理所應(yīng)得成為了面試官必問(wèn)、愛(ài)問(wèn)的核心知識(shí)點(diǎn)。

[[390964]]

很多朋友除了對(duì)索引、存儲(chǔ)原理有疑惑外，當(dāng)數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)，MySQL 還會(huì)涉及到一個(gè)幾乎必知必會(huì)的核心點(diǎn)——分庫(kù)分表。

畫(huà)外音：MySQL 是2019年 DB-Engines 評(píng)選的最受歡迎數(shù)據(jù)庫(kù)，這些年一直在前三甲徘徊。

問(wèn)題1：分庫(kù)分表解決什么問(wèn)題?

性能瓶頸MySQL是B+樹(shù)索引，當(dāng)數(shù)據(jù)量過(guò)大時(shí)，索引所消耗的磁盤(pán) IO 越來(lái)越多，查詢性能下降。高并發(fā)情況下，單表數(shù)據(jù)量過(guò)大導(dǎo)致 SQL 性能差，數(shù)據(jù)庫(kù)服務(wù)器負(fù)載太高再次導(dǎo)致性能下降，簡(jiǎn)直雪上加霜。

• 高可用：微服務(wù)架構(gòu)下，服務(wù)化無(wú)狀態(tài)型會(huì)導(dǎo)致壓力點(diǎn)在數(shù)據(jù)庫(kù)上，單機(jī)數(shù)據(jù)庫(kù)和主從結(jié)構(gòu)已經(jīng)不能滿足需求，同時(shí)數(shù)據(jù)災(zāi)備等維護(hù)成本也越來(lái)越高。
• 安全性：所有不同類型的數(shù)據(jù)全部存在一個(gè)數(shù)據(jù)庫(kù)中，當(dāng)數(shù)據(jù)庫(kù)宕機(jī)或發(fā)生物理性損壞時(shí)，容易造成不可估量的損失。

畫(huà)外音：雞蛋放到不同籃子里。

問(wèn)題2：分庫(kù)分表的邏輯是什么?

分庫(kù)分表的核心是數(shù)據(jù)拆分，分庫(kù)不一定分表，分表不一定分庫(kù)。

例如，MySQL 單表數(shù)據(jù)的極限在5000萬(wàn)左右，當(dāng)數(shù)據(jù)量超過(guò)5000萬(wàn)時(shí)，我們就需要分表進(jìn)行存放數(shù)據(jù)了。

簡(jiǎn)單來(lái)說(shuō)，就是將一個(gè)表結(jié)構(gòu)分為多個(gè)表，或者將一個(gè)表數(shù)據(jù)分片后放入多個(gè)表。這些表可以放在同一個(gè)數(shù)據(jù)庫(kù)里，也可以放到不同的數(shù)據(jù)庫(kù)中，甚至可以放到不同的數(shù)據(jù)庫(kù)實(shí)例。

問(wèn)題3：面試官問(wèn)，分庫(kù)分表方案有哪些?

數(shù)據(jù)拆分方式：

• 水平拆分
• 垂直拆分

常見(jiàn)方案：

• 客戶端分片
• 代理分片
• 支持事務(wù)的分布式數(shù)據(jù)庫(kù)

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文