一、mysql數(shù)據(jù)庫(kù)什么時(shí)候才需要分庫(kù)分表

如果系統(tǒng)處于高速發(fā)展階段，拿商城系統(tǒng)來說，一天下單量可能幾十萬(wàn)，那數(shù)據(jù)庫(kù)中的訂單表增長(zhǎng)就特別快，增長(zhǎng)到一定階段數(shù)據(jù)庫(kù)查詢效率就會(huì)出現(xiàn)明顯下降。

因此，當(dāng)單表數(shù)據(jù)增量過快，超過 500 萬(wàn)的數(shù)據(jù)量就要考慮分表了。

那如何分表呢？

分表有幾個(gè)維度，一是水平拆分和垂直拆分，二是單庫(kù)內(nèi)分表和多庫(kù)內(nèi)分表。

水平拆分和垂直拆分

就拿用戶表（user）來說，表中有 7 個(gè)字段：id,name,age,sex,nickname,description，如果 nickname 和 description 不常用，我們可以將其拆分為另外一張表：用戶詳細(xì)信息表，這樣就由一張用戶表拆分為了用戶基本信息表+用戶詳細(xì)信息表，兩張表結(jié)構(gòu)不一樣相互獨(dú)立。但是從這個(gè)角度來看垂直拆分并沒有從根本上解決單表數(shù)據(jù)量過大的問題，因此我們還是需要做一次水平拆分。

拆分表

還有一種拆分方法，比如表中有一萬(wàn)條數(shù)據(jù)，我們拆分為兩張表，id 為奇數(shù)的：1，3，5，7……放在 user1 中， id 為偶數(shù)的：2，4，6，8……放在 user2 中，這樣的拆分辦法就是水平拆分了。

水平拆分的方式有很多，除了上面說的按照 id 拆表，還可以按照時(shí)間維度去拆分，比如訂單表，可以按每日、每月等進(jìn)行拆分。

總結(jié)一下水平拆分和垂直拆分的特點(diǎn)：

單庫(kù)內(nèi)拆分和多庫(kù)拆分

拿水平拆分為例，每張表都拆分為了多個(gè)子表，多個(gè)子表存在于同一數(shù)據(jù)庫(kù)中。比如用戶表拆分為用戶 1 表、用戶 2 表。

單庫(kù)拆分

在一個(gè)數(shù)據(jù)庫(kù)中將一張表拆分為幾個(gè)子表在一定程度上可以解決單表查詢性能的問題，但是也會(huì)遇到一個(gè)問題：?jiǎn)螖?shù)據(jù)庫(kù)存儲(chǔ)瓶頸。

所以在業(yè)界用的更多的還是將子表拆分到多個(gè)數(shù)據(jù)庫(kù)中。比如下圖中，用戶表拆分為兩個(gè)子表，兩個(gè)子表分別存在于不同的數(shù)據(jù)庫(kù)中。

多庫(kù)拆分

一句話總結(jié)：分表主要是為了減少單張表的大小，解決單表數(shù)據(jù)量帶來的性能問題。

延伸閱讀：

二、為什么要分庫(kù)分表

答案很簡(jiǎn)單：數(shù)據(jù)庫(kù)出現(xiàn)性能瓶頸。用大白話來說就是數(shù)據(jù)庫(kù)快扛不住了。

數(shù)據(jù)庫(kù)出現(xiàn)性能瓶頸，對(duì)外表現(xiàn)有幾個(gè)方面：

在高并發(fā)場(chǎng)景下，大量請(qǐng)求都需要操作數(shù)據(jù)庫(kù)，導(dǎo)致連接數(shù)不夠了，請(qǐng)求處于阻塞狀態(tài)。

如果數(shù)據(jù)庫(kù)中存在一張上億數(shù)據(jù)量的表，一條 SQL 沒有命中索引會(huì)全表掃描，這個(gè)查詢耗時(shí)會(huì)非常久。

業(yè)務(wù)量劇增，單庫(kù)數(shù)據(jù)量越來越大，給存儲(chǔ)造成巨大壓力。

從機(jī)器的角度看，性能瓶頸無(wú)非就是 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)這些，要解決性能瓶頸最簡(jiǎn)單粗暴的辦法就是提升機(jī)器性能，但是通過這種方法成本和收益投入比往往又太高了，不劃算，所以重點(diǎn)還是要從軟件角度入手。