我们为什么在MySQL中几乎不使用分区表

本文主要是介绍我们为什么在MySQL中几乎不使用分区表，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

这是学习笔记的第 2330篇文章

在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完全可控）

小结：

我们不使用分区表，一方面是业务所需，另一方面我们提供了周期表解决了业务痛点，所以也算是一拍即合的一种策略。