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

但是在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或者业务同学忘记了，基本碰上就是一次数据故障。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!