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

本篇內(nèi)容介紹了“數(shù)據(jù)庫：分久必合，合久必分”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

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

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

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

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

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

• 高可用：微服務(wù)架構(gòu)下，服務(wù)化無狀態(tài)型會導(dǎo)致壓力點在數(shù)據(jù)庫上，單機(jī)數(shù)據(jù)庫和主從結(jié)構(gòu)已經(jīng)不能滿足需求，同時數(shù)據(jù)災(zāi)備等維護(hù)成本也越來越高。

• 安全性：所有不同類型的數(shù)據(jù)全部存在一個數(shù)據(jù)庫中，當(dāng)數(shù)據(jù)庫宕機(jī)或發(fā)生物理性損壞時，容易造成不可估量的損失。

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

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

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

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

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

問題3：面試官問，分庫分表方案有哪些?

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

• 水平拆分

• 垂直拆分

常見方案：

• 客戶端分片

• 代理分片

• 支持事務(wù)的分布式數(shù)據(jù)庫

“數(shù)據(jù)庫：分久必合，合久必分”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！