為什么在MySQL中幾乎不使用分區表

這篇文章主要介紹“為什么在MySQL中幾乎不使用分區表”，在日常操作中，相信很多人在為什么在MySQL中幾乎不使用分區表問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”為什么在MySQL中幾乎不使用分區表”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

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

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

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

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

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

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

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

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

問題2：日表和月表什么關系呢?月表是日表的聯合查詢還是數據鏡像?

日表和月表目前沒有直接的關聯，就是按照業務維度包括數據量進行綜合評估選定的，如果有的業務數據量不大，范圍查詢多一些，就推薦月表，如果數據量抖動大，數據量大，而且還會有變更操作，一般建議是日表，我們日表和月表的比例差不多是20:1

問題3：這些都是前期系統架構設計時規劃好的?有沒有后期改造的案例?如何去推動研發難度會不會很大

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

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

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

小結：

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

到此，關于“為什么在MySQL中幾乎不使用分區表”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！