一、為什么MySQL數(shù)據(jù)庫數(shù)據(jù)量大了要進(jìn)行分庫分表

隨著用戶量的激增和時(shí)間的堆砌，存在數(shù)據(jù)庫里面的數(shù)據(jù)越來越多，此時(shí)的數(shù)據(jù)庫就會產(chǎn)生瓶頸，出現(xiàn)資源報(bào)警、查詢慢等場景。

首先單機(jī)數(shù)據(jù)庫所能承載的連接數(shù)、I/O及網(wǎng)絡(luò)的吞吐等都是有限的，所以當(dāng)并發(fā)量上來了之后，數(shù)據(jù)庫就漸漸頂不住了。

再則，如果單表的數(shù)據(jù)量過大，查詢的性能也會下降。因?yàn)閿?shù)據(jù)越多 B+ 樹就越高，樹越高則查詢 I/O 的次數(shù)就越多，那么性能也就越差。

因?yàn)樯鲜龅脑?，不得已就得上分庫分表了?/p>

把以前存在一個(gè)數(shù)據(jù)庫實(shí)例里的數(shù)據(jù)拆分成多個(gè)數(shù)據(jù)庫實(shí)例，部署在不同的服務(wù)器中，這是分庫。

把以前存在一張表里面的數(shù)據(jù)拆分成多張表，這是分表。

一般而言：

延伸閱讀：

二、主要的單機(jī)存儲引擎

1、哈希存儲：hash的CRUD是非?？斓?。但缺點(diǎn)是不支持順序掃描。bitcask是一個(gè)基于hash表結(jié)構(gòu)的存儲系統(tǒng)。他將寫操作（包括刪除標(biāo)識）追加到文件尾。并定期合并新老文件&記錄。

2、B樹：既支持隨機(jī)讀取又支持范圍查找的系統(tǒng)。查找時(shí)間復(fù)雜度為logd(n)（d為每個(gè)節(jié)點(diǎn)的出度）。Mysql的InnoDB的引擎和OS的文件系統(tǒng)使用的就是B+樹。（為什么選擇使用B樹的變種B+樹，讀者有興趣可以去探究下。提示：磁盤讀?。?/p>

3、LSM樹(Log Structured Merge Tree)：由B+數(shù)改進(jìn)而來。其思想為：將增量寫操作保存在內(nèi)存中，超過閾值時(shí)刷入磁盤，從而減少隨機(jī)寫磁盤操作。讀操作則需要合并磁盤數(shù)據(jù)和內(nèi)存中的寫操作。通過Memtable/SSTable實(shí)現(xiàn)，實(shí)現(xiàn)細(xì)節(jié)在此不做深入探究。比較適合寫操作較多的業(yè)務(wù)場景。BigTable/HBase/Cassandra中的列簇的數(shù)據(jù)存儲方式采用的即是LSM樹。