[[386198]]

在Oracle中，使用分區(qū)表是一種很自然的事情，數(shù)據(jù)庫容量基本都是500G起，大小在5T以上都是很常見的。

但是在MySQL的使用中，我們幾乎不使用分區(qū)表，今天有同學(xué)在群里一起溝通，我就按照我的理解做了梳理。整體來說從功能上來說，Oracle有的大部分功能在MySQL分區(qū)表中基本存在，包括一些分區(qū)的細(xì)粒度管理。

所以如果單純從功能入手，確實難以找到很直接的理由來拒絕分區(qū)表。

我覺得主要是使用模式的差異，我們不使用的主要原因是避免單庫存儲過大，而且分區(qū)表變更相對會比較麻煩，在MySQL側(cè)，我們的目標(biāo)是讓數(shù)據(jù)庫更小巧輕量一些，可能更偏TP一些，我們目前是排除了分區(qū)表的設(shè)計，而且也明確寫進(jìn)了開發(fā)規(guī)范，如果按照數(shù)據(jù)類型來說，狀態(tài)表，流水表和配置表，這三種類型中也就只有流水日志表的數(shù)據(jù)都是建議使用周期表的形式進(jìn)行存儲，方便隨時擴(kuò)展，表結(jié)構(gòu)變更也方便T+1的變更模式

在這個基礎(chǔ)上，可以把這個問題轉(zhuǎn)化為，是使用分區(qū)表還是單表來存儲數(shù)據(jù)?這個問題我們調(diào)研過，目前來看，查詢復(fù)雜度的一些變更業(yè)務(wù)基本都能夠接受，而且風(fēng)險覆蓋度要小一些(程序側(cè)也不能完全保證SQL一定好使不走全表掃描)目前我們實現(xiàn)周期表(日表，月表，周表，年表，季表)中的日表和月表的自動擴(kuò)展，已經(jīng)接管了300多個周期表的自動管理。

此外，數(shù)據(jù)流轉(zhuǎn)體系中，分區(qū)表的模式對于數(shù)倉體系也不夠友好，如果ETL直接抽數(shù)據(jù)，基本需要在過濾條件的部分做一些取舍，影響還是相對很大的。

問題1：為啥Oracle分區(qū)表用的很常見 MySQL卻不推薦呢 挺疑問的。

因為是兩種不同的數(shù)據(jù)庫，拿MySQL當(dāng)Oracle用，會有很多不如意的地方。Oracle單庫過T很正常，TP+AP很強(qiáng)，原生的HTAP的支持，MySQL的AP相對要弱很多，單庫過T是不建議，我們的容量規(guī)劃目前是按照300G的容量規(guī)格設(shè)計的，基本上從設(shè)計層面能夠做到冷熱數(shù)據(jù)分離和規(guī)避數(shù)據(jù)過度增長。

問題2：日表和月表什么關(guān)系呢?月表是日表的聯(lián)合查詢還是數(shù)據(jù)鏡像?

日表和月表目前沒有直接的關(guān)聯(lián)，就是按照業(yè)務(wù)維度包括數(shù)據(jù)量進(jìn)行綜合評估選定的，如果有的業(yè)務(wù)數(shù)據(jù)量不大，范圍查詢多一些，就推薦月表，如果數(shù)據(jù)量抖動大，數(shù)據(jù)量大，而且還會有變更操作，一般建議是日表，我們?nèi)毡砗驮卤淼谋壤畈欢嗍?0:1

問題3：這些都是前期系統(tǒng)架構(gòu)設(shè)計時規(guī)劃好的?有沒有后期改造的案例?如何去推動研發(fā)難度會不會很大

這個我認(rèn)為不算前期規(guī)劃，算是迭代改進(jìn)，我們提供的一個福利就是改造成日表后，日表的擴(kuò)展和數(shù)據(jù)清理都是我們來干了，業(yè)務(wù)很happy，而在以前，可能還會有手工維護(hù)Excel列表或者一些元數(shù)據(jù)配置的模式來記錄不同業(yè)務(wù)的表的擴(kuò)展情況，有種手工記賬的感覺，如果DBA或者業(yè)務(wù)同學(xué)忘記了，基本碰上就是一次數(shù)據(jù)故障。

所以我們寫了自動管理的服務(wù)，包括單機(jī)和集群中間件的周期表管理，基本上我們就不用手工干預(yù)了。

對于業(yè)務(wù)來說很大的痛點就是表如何擴(kuò)展(有時候忘記了后果挺嚴(yán)重的)，數(shù)據(jù)清理(如果不拆表，按照delete模式很痛苦)和表變更(T+1的模式對于業(yè)務(wù)來說是可用接受的，對于DBA完全可控)

小結(jié)：

我們不使用分區(qū)表，一方面是業(yè)務(wù)所需，另一方面我們提供了周期表解決了業(yè)務(wù)痛點，所以也算是一拍即合的一種策略。

本文轉(zhuǎn)載自微信公眾號「楊建榮的學(xué)習(xí)筆記 」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系楊建榮的學(xué)習(xí)筆記公眾號。