MySQL 分区表，为啥分区键必须是主键的一部分？

Posted 2023-04-06

参考技术A 随着业务的不断发展，数据库中的数据会越来越多，相应地，单表的数据量也会越到越大，大到一个临界值，单表的查询性能就会下降。

这个临界值，并不能一概而论，它与硬件能力、具体业务有关。

虽然在很多 mysql 运维规范里，都建议单表不超过 500w、1000w。

但实际上，我在生产环境，也见过大小超过 2T，记录数过亿的表，同时，业务不受影响。

单表过大时，业务通常会考虑两种拆分方案：水平切分和垂直切分。

水平切分，拆分的维度是行，一般会根据某种规则或算法将表中的记录拆分到多张表中。

拆分后的表既可在一个实例，也可在多个不同实例中。如果是后者，又会涉及到分布式事务。

垂直切分，拆分的维度是列，一般是将列拆分到多个业务模块中。这种拆分更多的是上层业务的拆分。

从改造的复杂程度来说，前者小于后者。

所以，在单表数据量过大时，业界用得较多的还是水平拆分。

常见的水平拆分方案有：分库分表、分区表。

虽然分库分表是一个比较彻底的水平拆分方案，但一方面，它的改造需要一定的时间；另一方面，它对开发的能力也有一定的要求。相对来说，分区表就比较简单，也无需业务改造。

很多人可能会认为 MySQL 的优势在于 OLTP 应用，对于 OLAP 应用就不太适合，所以，也不太推荐分区表这种偏 OLAP 的特性。

但实际上，对于某些业务类型，还是比较适合使用分区表的，尤其是那些有明显冷热数据之分，且数据的冷热与时间相关的业务。

下面，我们看看分区表的优点：

遗憾的是，MySQL 分区表不支持并行查询。理论上，当一个查询涉及到多个分区时，分区与分区之间应进行并行查询，这样才能充分利用多核 CPU 资源。

但 MySQL 并不支持，包括早期的官方文档，也提到了这个问题，也将这个功能的实现放到了优先级列表中。

在 MySQL 5.7 中，对于分区表，有个很重大的更新，即 InnoDB 存储引擎原生支持了分区，无需再通过 ha_partition 接口来实现。

所以，在 MySQL 5.7 中，如果要创建基于 MyISAM 存储引擎的分区表，会提示 warning 。

而在 MySQL 8.0 中，则更为彻底，server 层移除了 ha_partition 接口代码。

如果要使用分区表，只能使用支持原生分区的存储引擎。在 MySQL 8.0 中，就只有 InnoDB。

这就意味着，在 MySQL 8.0 中，如果要创建 MyISAM 分区表，基本上就不可能了。

这也从另外一个角度说明了为什么生产上不建议使用 MyISAM 表。

在使用分区表时，大家常常会碰到下面这个报错。

即分区键必须是主键的一部分。

上面的 opr 是一张操作流水表。其中，opr_no 是操作流水号，一般都会被设置为主键，opr_date 是操作时间。基于操作时间来进行分区，是一个常见的分区场景。

为了突破这个限制，可将 opr_date 作为主键的一部分。

但是这么创建，又会带来一个新的问题，即对于同一个 opr_no ，可插入到不同分区中。如下所示：

这实际上违背了业务对于 opr_no 的唯一性要求。

既然这样，有的童鞋会建议给 opr_no 添加个唯一索引，But，现实是残酷的。

即便是添加唯一索引，分区键也必须包含在唯一索引中。

总而言之，对于 MySQL 分区表，无法从数据库层面保证非分区列在表级别的唯一性，只能确保其在分区内的唯一性。

这也是 MySQL 分区表所为人诟病的地方之一。

但实际上，这个锅让 MySQL 背并不合适，对于 Oracle 索引组织表（ InnoDB 即是索引组织表），同样也有这个限制。

Oracle 官方文档（ http://docs.oracle.com/cd/E11882_01/server.112/e40540/schemaob.htm#CNCPT1514），在谈到索引组织表（Index-Organized Table，简称 IOT）的特性时，就明确提到了 “分区键必须是主键的一部分”。

下面，我们看看刚开始的建表 SQL ，在 Oracle 中的执行效果。

同样报错。

注意，这里指定了 ORGANIZATION INDEX ，创建的是索引组织表。

看来，分区键必须是主键的一部分并不是 MySQL 的限制，而是索引组织表的限制。

之所以对索引组织表有这样的限制，个人认为，还是基于性能考虑。

假设分区键和主键是两个不同的列，在进行插入操作时，虽然也指定了分区键，但还是需要扫描所有分区才能判断插入的主键值是否违反了唯一性约束。这样的话，效率会比较低下，违背了分区表的初衷。

而对于堆表则没有这样的限制。

在堆表中，主键和表中的数据是分开存储的，在判断插入的主键值是否违反唯一性约束时，只需利用到主键索引。

但与 MySQL 不一样的是，Oracle 实现了全局索引，所以针对上面的，同一个 opr_no，允许插入到不同分区中的问题，可通过全局唯一索引来规避。

但 MySQL 却无能为力，之所以会这样，是因为 MySQL 分区表只实现了本地分区索引（Local Partitioned Index），而没有实现 Oracle 中的全局索引（Global Index）。

本地分区索引和全局索引的原理图如下所示：

结合原理图，我们来看看两种索引之间的区别：

1. MySQL 分区表关于“分区键必须是唯一键（主键和唯一索引）的一部分”的限制，本质上是索引组织表的限制。

2. MySQL 分区表只实现了本地分区索引，没有实现全局索引，所以无法保证非分区列的全局唯一。

如果要保证非分区列的全局唯一，只能依赖业务实现了。

3. 不推荐使用 MyISAM 分区表。当然，任何场景都不推荐使用 MyISAM 表。

Mysql第八天 分区与分表

分区表

主要提供例如以下的特性，或者适合如此场景：

• 数据量非常大， 或者仅仅有表中最后的部分有热点数据。其它均为历史数据
• 分区表数据更easy维护，能够对独立的分区删除等操作
• 分区表的数据能够分布在不同的物理设备上。从而高效地利用多个硬件设备。
• 能够避免一些特殊瓶颈。比方InnoDB的单个索引的相互排斥訪问
• 能够备份和恢复独立的分区

创建分区表

通常有这么几种分法。由于主键或者是唯一约束键必须有一部分包括在分区键中，所以一般要不无主键，要不就依照自增主键的id进行范围分区，要不就把分区字段和主键一起作为联合主键。
另一些其它的限制，比方分区键的运算结果必须为整数

Range分区

CREATE TABLE biz_order(
id bigint(20) NOT NULL AUTO_INCREMENT,
created DATETIME NOT NULL COMMENT ‘创建时间‘,
PRIMARY KEY (id, created)) ENGINE=InnoDB PARTITION BY RANGE(YEAR(created))(
  PARTITION p_2010 VALUES LESS THAN (2015),
  PARTITION p_latest VALUES LESS THAN MAXVALUE);

这样的分区。最新的那个区显然会有最多的热点数据。 能够再使用Hash子分区来降低竞争
- 除了使用YEAR, TO_DAY等日期函数外。还能够使用其数学函数。比方取模，按7取模是周几等

List分区

是用IN来做列值匹配的集合。

比方能够依照地区来分为东西南北几个区：

PARTITION BY LIST(store_id)
    PARTITION pNorth VALUES IN (3,5,6,9,17),
    PARTITION pEast VALUES IN (1,2,10,11,19,20),
    PARTITION pWest VALUES IN (4,12,13,14,18),
    PARTITION pCentral VALUES IN (7,8,15,16)
);

这样的假设插入语句不在IN中。则会插入失败

Hash分区

PARTITIONS为分区的数量。 即会依据分区键的值计算出一个hash值，然后以4为模进行存储。优点是。不用再又一次建分区了。

PARTITION BY HASH(store_id)
PARTITIONS 4;

还有Key分区，用的太少，不说了

操作分区表

添加删除分区等语句看这里

分区表由多个底层表构成，底层表跟普通表没什么差别，其索引也是分别在各个表中的索引。 分区表仅仅是会在一个非常粗的粒度上决定一下去哪个底层表继续查询。

• SELECT 锁住底层表。优化器先推断能够过滤部分的分期，然后再调用存储引擎接口訪问各个分区
• INSERT DELETE同行
• UPDATE 操作会须要设计更新后推断在哪个分区，假设插入到了新分区。那么则删除原分区中的数据。
• 使用WHERE语句最好能够明白用到分区的关键字，这样能够非常好的命中分区
• 锁住底层表不一定是表锁。会用到存储引擎自己的行级锁

怎样使用

使用分区表肯定是由于数据量非常大。这个时候索引已经不能非常好的起作用了。
能够不使用索引，而用粗粒度的命中分区表，然后全表扫描。

或者是针对热点数据。单独使用一个区让这个区都能够放到缓存中，这样就会有一个热点的非常小的分区，能够对其使用索引。

另外一些可能的问题：

• NULL值。由于TO_DAY等方法NULL值为无效入參，会把值放在第一个分区，这个时候SELECT的时候可能会须要查找第一个和命中的分区这样两个分区。这样可能会有非常多的性能损耗。解决的方法是使第一个分区尽可能的小。第二个办法是直接使用RANGE COLUMNS()而不使用函数
• 分区列和索引列应该用同一个列。假设不是，会导致无法过滤的问题
• 寻找分区的成本可能会比較高
• 维护分区的成本，比方alter等语句改变分区个数，或者其它涉及数据迁移的操作

分区表的查询

要在WHERE后面带分区列，且不能是表达式
使用EXPLAIN PARTITIONS SELECT来推断是否进行了分区过滤

分表

分区表还是一张表，是一种逻辑上的实现，主要解决的是单表数据过大。索引效率低的问题，非常适合大量历史数据，少量活跃数据的场景。

把数据保存在不同的区域。

分表是真的有多张表。基于分表还能够做分库，能够提升并发性能。以及磁盘I/O的性能。

二者能够配合使用。

使用集群的方式

要配合复制使用。仅仅是把查询请求进行了分摊。
可是这样不会影响代码层。

使用业务逻辑划分

可一个依据用户id来分，每一个用户一张表，这样须要每有新的用户都建表了。

还有经常使用的做法是预先设计好比方100张表，然后对数据的一个字段做hash，然后对100取模。

又或者依据时间来进行切割，这样的的优点是，假设依据时间做统计的时候能够不用UNION

上面的分表方式都不能解决依据server压力进行选择的问你，而且也不能比較均匀的保存数据。

分表之后要考虑这样几个操作以后可能会带来的问题：

• 分页， 主要看分页情况下排序的字段是什么，假设是时间，那么依照时间段分表是比較好的， 假设会涉及到多个表的UNION，那么就会比較耗费性能。
• 插入。 更新。 主要是更新的时候的主键的问题。由于分表之后主键不唯一了，因此须要用分表列和自增列做联合主键。
• 分组。统计。 这个跟分页考虑的情况差点儿相同，也是主要涉及排序的问题。比方假设每次都是须要依照用户统计信息的话，那么依照用户分表的选择是没错的。
• 表的分发跟业务非常比較大的关系。要尽量考虑比較多的因素和场景。
• 通用一些的解决的方法是。对分页字段使用搜索引擎
• 或者对分页和排序字段单独列一张表不分，作为查询的索引。

使用merge存储引擎

基本表:
CREATE TABLE TEST_MERGE_1(
ID INT(5) NOT NULL,
VALUE VARCHAR(100) NOT NULL,
PRIMARY KEY(ID)
);
CREATE TABLE TEST_MERGE_2(
ID INT(5) NOT NULL,
VALUE VARCHAR(100) NOT NULL,
PRIMARY KEY(ID)
);
MERGE表：
CREATE TABLE TEST_MERGE(
ID INT(5) NOT NULL,
VALUE VARCHAR(100) NOT NULL,
PRIMARY KEY(ID)
) TYPE=MRG_MyISAM INSERT_METHOD=LAST UNION=(TEST_MERGE_1,TEST_MERGE_2);

基本表必须是MYISAM类型的。
基本表的数据结构必须一致。
order by等语句，我想的是由于Merge表里有基本表共同的索引，所以，排序的时候应该是，都先比較第一个，然后再。。。有点像经常使用的大文件分成多个小文件，然后分别排序。最后merge的过程。

主要是能够提供比較好的编码界面。