为什么在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中几乎不使用分区表”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！