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

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

[[390964]]

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

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

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

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

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

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

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

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

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

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

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

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

• 水平拆分
• 垂直拆分

常見方案：

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

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

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