MySQL分区表简介

我们的业务只存近一段时间的数据，因此有大量表需要清理 历史 数据，目前使用的delete清理数据，存在以下问题。为避免同时支持大量delete，我们的清理任务只在低峰期串行执行，导致任务过多时需要排队，甚至失败的情况；数据清理使用delete语句，表数据量较大时，对数据库造成很大压力；即使我们删除了旧数据，已删除的数据仍占据存储空间，底层数据文件并没有立刻变小，以至于形成数据空洞。

查看MySQL官方文档时，发现了分区表，因此基于官方文档总结一下。

MySQL逻辑上为一个表，物理上存储在多个文件中，这是 MySQL 支持的功能（5.1 开始）, 8.0 版本只 InnoDB 和 NDB 支持分区表。

优点：

缺点：

根据分区表键值的范围把数据存储到表的不同分区中，适用于以时间或日期作为分区类型，方便数据清理。

小提示：

1.当插入数据分区不存在时会报错：Table has no partition for value xxx

2.Range类型分区字段必须是数值，时间类型可用函数转换为数值；

3.分区字段列值可以为null，所有为null的数据将存在最小的分区中；

按分区键取值的列表进行分区，每一行数据须找到对应的分区列表，否则数据插入失败

小提示：

根据指定分区表达式的整数值以及分区数进行数据划分(mod函数)

小提示：

按键分区类似于按哈希分区，只是哈希分区使用用户定义的表达式，用于键分区的哈希函数由 MySQL 服务器提供。NDB 集群为此使用 MD5() 对于使用其他存储引擎的表，服务器使用自己的内部哈希函数。

小提示：

子分区(subpartitioning)也称为复合分区(composite partitioning) ，是已分区表中每个分区的进一步划分

小提示：

小提示：

对底层表的封装，意味着索引也是按照分区的子表定义的，而没有全局索引。（所以即使有唯一性索引，在不同子表中可能会有重复数据）

单表数据量超大时索引失效

将单表分区成数个区域，通过分区函数，可以快速地定位到数据的区域。而且相比于索引，分区不需要额外的数据结构记录每个分区的数据，代价更低。只需要一个简单的表达式就可以指向正确的分区

​ 可以只是用简单的分区方式存放表，不要任何索引，只要将查询定位到需要的大致数据位置，通过where条件，将需要的数据限制在少数分区中，则效率是很高的。WARNNING：查询需要扫描的分区个数限制在一个很小的数量。

​ 如果数据有明显的“热点”，可以将热点数据单独放在一个分区，让这个分区的数据能够有机会都缓存在内存中。

​ 如果分区表达式的值可以是NULL：第一个分区会使一个特殊分区。以partition by range year(order_date)为例，所有在order_date列为NULL或者非法值的数据都会被放到第一个分区。那么所有的查询在定位分区后都会增加扫描第一个分区。而且如果第一个分区很大的时候，查询的成本会被这个“拖油瓶”分区无情的增加。

​ 创建一个无用的第一分区可以解决这个问题，partition p_nulls values less than (0)

​ 对于分区列和索引列不匹配的查询，虽然查询能够使用索引，但是无法通过分区定位到目标数据的分区（也就是数据分布相对更加分散）,需要遍历每个分区内的索引，除非查询中的条件同时也包含分区条件。所以期望分区条件范围被热门查询索引所包含。

​ 对于 范围分区 技术，需要适当限制分区的数量，否则对于大量数据批量导入的场景，选择分区的成本过高。对于大多数系统，100个左右的分区是没有问题的。

---