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

小提示：

小提示：

在 Mysql 5.6 之前版本中 ， 如果要修改一个表的ddl信息 ，需要锁表 。

具体步骤如下:

下面是Mysql官方文档对于DDL *** 作的总结:

http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html

http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html

可以使用 Alter 语句支持 DDL 特性 ，比如可以用 LOCK = NONE 无锁变更。

percona是一个开源产品 , 是管理Mysql的工具。

PT-OSC(Percona Toolkit Online Schema Change)

https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html

Percona Toolkit 包含很多 mysql 管理的功能 ，现在要说的是 online-schema-change上

PT-OSC 原理是建表 ，使用触发器同步数据 ，然后原子性rename。

这样可以支持在线无锁，不停机Online-DDL 。

具体步骤如下：

Percona 有一些限制和缺陷 ，根据它的原理 ，原表不能存在触发器 ，这玩意是唯一。另外原表必须存在PK或者UK。另外就是触发器的问题了，触发器带来性能开销，并且无法停止，那我就不能控制我同步的开关和速度。

但是gh-ost说它可以。

https://github.com/github/gh-ost

go-ost基于bin-log同步 ， 基于binlog肯定都是伪装成一个replica。

由于使用单线程回放binlog来替换触发器，所以增量DML回放效率不如触发器，因为pt-osc的增量回放并发度是与业务DML并发度相同的，是多线程的。

相对于percona的优势是:

因为出的太晚了 ，然后percona 和 gh-ost等等开源产品已经大规模实践了，Mysql就更加没什么实践案例和经验了，大家就不太愿意尝试或者迁移了。

大厂来说基本上都是平台封装了，类似idb ，会把无锁变更细节屏蔽了，只需要提工单就可以了 ，但是底层基本上也是建表同步rename个思路。

小公司的话，可以使用percona 、 go-ost 等工具。

MySQL 8.0 Online DDL和pt-osc、gh-ost深度对比分析

Mysql Online DDL

pt-online-schema-change

gh-ost

MySQL5.6在线表结构变更（online ddl）总结

语法：

第二个SELECT语句返回一个数字，该数字指示如果不使用LIMIT语句写入第一个SELECT将会返回多少行。

如果您使用的是 SELECT SQL_CALC_FOUND_ROWS ，MySQL 必须计算整个结果集中有多少行。但是，这比不使用LIMIT再次运行查询要快，因为不需要将结果集发送到 Client 端。

中文——mysql5.7官方文档

在mysql8.0版本的官方文档中，不推荐使用 SQL_CALC_FOUND_ROWS 选项，并计划在后续版本中废弃。

mysql8.0文档

注意：

mysql会为当前连接保存这个值，各个连接的SQL_CALC_FOUND_ROWS结果互不影响

两条sql语句可以简化成一条sql语句，看似简单了，实则不然。

原因:

来源—— SQL_CALC_FOUND_ROWS的用法

哪个最快？SELECT SQL_CALC_FOUND_ROWS FROM table ，或 SELECT COUNT(*)

---