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