？在Oracle中，使用分区表是一件很自然的事情。数据库容量基本都是500G起步，5T以上的规模是很常见的。但是在MySQL的使用中，我们几乎不使用分区表。今天群里有同学交流，所以根据自己的理解整理一下。总体来说，在功能上，Oracle的大部分功能基本都存在于MySQL的分区表中，包括对部分分区的细粒度管理。因此，如果单从功能入手，确实很难找到一个非常直接的理由来拒绝分区表。我认为这主要是由于使用模式的差异。我们不使用它的主要原因是避免单个数据库存储过多，更改分区表相对麻烦。在MySQL这边，我们的目标是让数据库更小、更轻，这可能更偏TP，我们目前已经排除了分区表的设计，而且也明确写进了开发规范。从数据类型来看，有状态表、流量表和配置表，这三种类型中只有流量日志表。建议将所有数据以元素周期表的形式存储，方便随时扩容，表结构变更也方便T+1变更方式。在此基础上，这个问题可以转化为使用分区表还是单表来存储数据？我们对这个问题进行了研究。目前查询复杂度的一些变化基本可以接受，风险覆盖范围较小（程序端不能完全保证SQL一定要好，才不用全表扫描）。目前，我们已经实现了元素周期表（Daily,Monthly,Weekly,Yearly,Seasonal）中日表和月表的自动扩展，已经接管了300多张元素周期表的自动管理。另外，在数据传输系统中，分区表的模式对数据仓库系统不够友好。如果ETL直接抽取数据，基本上需要在过滤条件上做一些取舍，影响比较大。问题一：为什么Oracle分区表常用而MySQL不推荐？这很值得怀疑。因为有两个不同的数据库，用MySQL来代替Oracle会有很多不尽如人意的地方。Oracle单库超过T很正常，TP+AP很强，而原生HTAP的支持，MySQL的AP相对较弱，不建议单库超过T。我们的容量规划目前是按照300G的容量规格来设计的。基本上，从设计层面，就可以做到冷热数据分离，避免数据增长过快。问题二：日表和月表有什么关系？月表是日表联合查询还是数据镜像？日表和月表目前没有直接关系。根据包括数据量在内的业务维度综合评估选择。对于一些数据量小，范围查询比较多的业务，推荐使用月表。如果数据量比较抖动，数据量大，还会有变更操作，一般推荐是日表。我们日表和月表的比例几乎是一样的。是20:1问题3：这些都是在系统架构设计初期就规划好的？有没有后期改造的案例？如何推动研发会很困难？一个好处就是改造成日表后，我们再做日表的扩容和数据清洗，业务非常愉快。以往可能需要人工维护Excel列表或者一些元数据配置方式来记录不同的数据。业务表的扩展有种手工记账的感觉。如果DBA或者业务同学忘记了，基本就是数据故障了。所以我们写了自动管理服务，包括单机和集群中间件的元素周期表管理，基本上不需要人工干预。业务最大的痛点是如何扩表（有时候遗忘的后果很严重）、数据清洗（如果不拆表，按照delete方式很痛苦）和改表（T+1模式对于业务是可用的，是可以接受的，对于DBA是完全可控的）总结：我们不使用分区表。一方面是业务需要。另一方面，我们提供了一个元素周期表来解决业务痛点，所以也是一拍即合的策略。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
