产品中心
前言：
分区是一种表的设计模式，通俗地讲表分区是将一大表，根据条件分割成若干个小表。但是对于应用程序来讲，分区的表和没有分区的表是一样的。换句话来讲，分区对于应用是透明的，只是数据库对于数据的重新整理
随着业务的不断发展，数据库中的数据会越来越多，相应地，单表的数据量也会越到越大，大到一个临界值，单表的查询性能就会下降。
这个临界值，并不能一概而论，它与硬件能力、具体业务有关。
虽然在很多 MySQL 运维规范里，都建议单表不超过 500w、1000w。
但实际上，我在生产环境，也见过大小超过 2T，记录数过亿的表，同时，业务不受影响。
单表过大时，业务通常会考虑两种拆分方案：水平切分和垂直切分。
水平切分，拆分的维度是行，一般会根据某种规则或算法将表中的记录拆分到多张表中。
拆分后的表既可在一个实例，也可在多个不同实例中。如果是后者，又会涉及到分布式事务。
垂直切分，拆分的维度是列，一般是将列拆分到多个业务模块中。这种拆分更多的是上层业务的拆分。
从改造的复杂程度来说，前者小于后者。
所以，在单表数据量过大时，业界用得较多的还是水平拆分。
常见的水平拆分方案有：分库分表、分区表。
虽然分库分表是一个比较彻底的水平拆分方案，但一方面，它的改造需要一定的时间；另一方面，它对开发的能力也有一定的要求。相对来说，分区表就比较简单，也无需业务改造。
很多人可能会认为 MySQL 的优势在于 OLTP 应用，对于 OLAP 应用就不太适合，所以，也不太推荐分区表这种偏 OLAP 的特性。
但实际上，对于某些业务类型，还是比较适合使用分区表的，尤其是那些有明显冷热数据之分，且数据的冷热与时间相关的业务。
下面我们看看分区表的优点：
提升查询性能：
对于分区表的查询操作，如果查询条件中包含分区键，则这个查询操作就只会被下推到符合条件的分区内进行，无关分区将自动过滤掉。
在数据量比较大的情况下，能提升查询速度。
对业务透明：
将表从一个非分区表转换为分区表，业务端无需做任何改造。
管理方便：
在对单个分区进行删除、迁移和维护时，不会影响到其它分区。
尤其是针对单个分区的删除（DROP）操作，避免了针对这个分区所有记录的 DELETE 操作。
遗憾的是，MySQL 分区表不支持并行查询。理论上，当一个查询涉及到多个分区时，分区与分区之间应进行并行查询，这样才能充分利用多核 CPU 资源。
但 MySQL 并不支持，包括早期的官方文档，也提到了这个问题，也将这个功能的实现放到了优先级列表中。
结合原理图，我们来看看两种索引之间的区别：
1. MySQL 分区表关于“分区键必须是唯一键（主键和唯一索引）的一部分”的限制，本质上是索引组织表的限制。
2. MySQL 分区表只实现了本地分区索引，没有实现全局索引，所以无法保证非分区列的全局唯一。
如果要保证非分区列的全局唯一，只能依赖业务实现了。
3. 不推荐使用 MyISAM 分区表。当然，任何场景都不推荐使用 MyISAM 表。
到此这篇关于MySQL 分区表中分区键为什么必须是主键的一部分的文章就介绍到这了,更多相关MySQL 分区表内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
