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) ，是已分区表中每个分区的进一步划分

小提示：

小提示：

1.首先我想知道SQBM字段上是否存在INDEX，INDEX类型是global还是local partition。

如果SQBM上没有INDEX的话，则3个SQL的运行性能是一样的。都只会使用PK的index

2.如果表上存在(ID,SQBM)的组合INDEX,那么你添加SQBM条件是有作用的。

3.对于SQL2，SQL3 条件顺序颠倒是不会影响性能的。

谈点我的看法

分区表：可以想象为磁盘的多个分区一样，可以减少全盘扫描的可能。直接定位到某个分区表上

类似要在电脑上找文件，直接到c盘，防止在D E F盘扫描一样，从而减少io压力，提升性能。在查询上分区表表现还不是十分突出，但是删除，作数据迁移的时候就很明显了。

索引：索引在查询上可以快速定位符合要求的纪录，查询通过索引，也可以防止全表扫描，类似直接定位excel里面的行号一样。但是索引维护对insert update影响必须要考虑到

简单点理解2者区别，从数据库角度来看，分区表更侧向于片状范围划定，索引更趋向于线性定位

---