一、mysql數(shù)據(jù)庫(kù)什么時(shí)候才需要分庫(kù)分表
如果系統(tǒng)處于高速發(fā)展階段,拿商城系統(tǒng)來(lái)說(shuō),一天下單量可能幾十萬(wàn),那數(shù)據(jù)庫(kù)中的訂單表增長(zhǎng)就特別快,增長(zhǎng)到一定階段數(shù)據(jù)庫(kù)查詢效率就會(huì)出現(xiàn)明顯下降。
因此,當(dāng)單表數(shù)據(jù)增量過(guò)快,超過(guò) 500 萬(wàn)的數(shù)據(jù)量就要考慮分表了。
那如何分表呢?
分表有幾個(gè)維度,一是水平拆分和垂直拆分,二是單庫(kù)內(nèi)分表和多庫(kù)內(nèi)分表。
水平拆分和垂直拆分
就拿用戶表(user)來(lái)說(shuō),表中有 7 個(gè)字段:id,name,age,sex,nickname,description,如果 nickname 和 description 不常用,我們可以將其拆分為另外一張表:用戶詳細(xì)信息表,這樣就由一張用戶表拆分為了用戶基本信息表+用戶詳細(xì)信息表,兩張表結(jié)構(gòu)不一樣相互獨(dú)立。但是從這個(gè)角度來(lái)看垂直拆分并沒有從根本上解決單表數(shù)據(jù)量過(guò)大的問(wèn)題,因此我們還是需要做一次水平拆分。
拆分表
還有一種拆分方法,比如表中有一萬(wàn)條數(shù)據(jù),我們拆分為兩張表,id 為奇數(shù)的:1,3,5,7……放在 user1 中, id 為偶數(shù)的:2,4,6,8……放在 user2 中,這樣的拆分辦法就是水平拆分了。
水平拆分的方式有很多,除了上面說(shuō)的按照 id 拆表,還可以按照時(shí)間維度去拆分,比如訂單表,可以按每日、每月等進(jìn)行拆分。
每日表:只存儲(chǔ)當(dāng)天的數(shù)據(jù)。每月表:可以起一個(gè)定時(shí)任務(wù)將前一天的數(shù)據(jù)全部遷移到當(dāng)月表。歷史表:同樣可以用定時(shí)任務(wù)把時(shí)間超過(guò) 30 天的數(shù)據(jù)遷移到 history 表。總結(jié)一下水平拆分和垂直拆分的特點(diǎn):
垂直拆分:基于表或字段劃分,表結(jié)構(gòu)不同。水平拆分:基于數(shù)據(jù)劃分,表結(jié)構(gòu)相同,數(shù)據(jù)不同。單庫(kù)內(nèi)拆分和多庫(kù)拆分
拿水平拆分為例,每張表都拆分為了多個(gè)子表,多個(gè)子表存在于同一數(shù)據(jù)庫(kù)中。比如用戶表拆分為用戶 1 表、用戶 2 表。
單庫(kù)拆分
在一個(gè)數(shù)據(jù)庫(kù)中將一張表拆分為幾個(gè)子表在一定程度上可以解決單表查詢性能的問(wèn)題,但是也會(huì)遇到一個(gè)問(wèn)題:?jiǎn)螖?shù)據(jù)庫(kù)存儲(chǔ)瓶頸。
所以在業(yè)界用的更多的還是將子表拆分到多個(gè)數(shù)據(jù)庫(kù)中。比如下圖中,用戶表拆分為兩個(gè)子表,兩個(gè)子表分別存在于不同的數(shù)據(jù)庫(kù)中。
多庫(kù)拆分
一句話總結(jié):分表主要是為了減少單張表的大小,解決單表數(shù)據(jù)量帶來(lái)的性能問(wèn)題。
延伸閱讀:
二、為什么要分庫(kù)分表
答案很簡(jiǎn)單:數(shù)據(jù)庫(kù)出現(xiàn)性能瓶頸。用大白話來(lái)說(shuō)就是數(shù)據(jù)庫(kù)快扛不住了。
數(shù)據(jù)庫(kù)出現(xiàn)性能瓶頸,對(duì)外表現(xiàn)有幾個(gè)方面:
大量請(qǐng)求阻塞在高并發(fā)場(chǎng)景下,大量請(qǐng)求都需要操作數(shù)據(jù)庫(kù),導(dǎo)致連接數(shù)不夠了,請(qǐng)求處于阻塞狀態(tài)。
SQL 操作變慢如果數(shù)據(jù)庫(kù)中存在一張上億數(shù)據(jù)量的表,一條 SQL 沒有命中索引會(huì)全表掃描,這個(gè)查詢耗時(shí)會(huì)非常久。
存儲(chǔ)出現(xiàn)問(wèn)題業(yè)務(wù)量劇增,單庫(kù)數(shù)據(jù)量越來(lái)越大,給存儲(chǔ)造成巨大壓力。
從機(jī)器的角度看,性能瓶頸無(wú)非就是 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)這些,要解決性能瓶頸最簡(jiǎn)單粗暴的辦法就是提升機(jī)器性能,但是通過(guò)這種方法成本和收益投入比往往又太高了,不劃算,所以重點(diǎn)還是要從軟件角度入手。