數(shù)據(jù)庫：分久必合，合久必分

作者：58沈劍 2021-04-01 16:57:53

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

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

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

[[390964]]

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

問題1：分庫分表解決什么問題?

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

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

畫外音：雞蛋放到不同籃子里。

問題2：分庫分表的邏輯是什么?

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

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

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