DBA 必会的 MySQL 5.7 新特性

最近我们在使用 MySQL 的时候，遇到了一个问题。一个线上系统的整个 MySQL 数据库实际大小只有 1.3 G。但是阿里云却给我们频繁的发报警信息，说我们的 10G 空间占用已超过 80%。也就是说整个数据库占用的存储空间已经超过 8G 了。我反复的确认了，我的数据库整个大小才 1.3 G。备份和 binlog 都不占用实例空间，为毛说我们占了 8G。

一番，百度，谷歌三部曲之后，发现阿里云上没有合理的描述，于是只能提交一个工单问问了。

经过一番沟通后，发现占的 8G 大部分是被 undo log 占去了。既然是 log，那么我们能不能删除一部分呢？答案是 5.6 之前，还真不能通过删除(?)解决。

不能删除，是因为 5.6 之前，没有提供这样的功能。有人在 2003 就给 MySQL 提了 bug，直到 2015 年 MySQL 5.7 的版本发布，才最终有了解决方案。而，5.6 之前的数据，想要删除 undo log，必须要通过迁移来解决。简直是坑死了。

所以说，MySQL 5.7 的新特性，或者说每一个版本的新特性，我们还是有必要了解的。

MySQL 5.7 增加了安全性。

新增 JSON 结构

随着非结构化数据存储需求的持续增长，各种非结构化数据存储的数据库应运而生（如MongoDB）。从最新的数据库使用排行榜来看，MongoDB已经超过了PostgreSQL，其火热程度可见一斑。

各大关系型数据库也不甘示弱，纷纷提供对JSON的支持，以应对非结构化数据库的挑战。MySQL数据库从5.7.8版本开始，也提供了对JSON的支持。其使用方式如下：

CREATE TABLE xttblog (jdoc JSON);
INSERT INTO xttblog VALUES('{"key1": "value1", "key2": "value2"}');

MySQL对支持JSON的做法是，在server层提供了一堆便于操作JSON的函数，至于存储，就是简单地将JSON编码成BLOB，然后交由存储引擎层进行处理，也就是说，MySQL 5.7的JSON支持与存储引擎没有关系，MyISAM 存储引擎也支持JSON 格式。

MySQL支持JSON以后，总是避免不了拿来与MongoDB进行一些比较。但是，MySQL对JSON的支持，至少有两点能够完胜MongoDB：

• 可以混合存储结构化数据和非结构化数据，同时拥有关系型数据库和非关系型数据库的优点
• 能够提供完整的事务支持

MySQL 新增 generate column

generated column是MySQL 5.7引入的新特性，所谓generated column，就是数据库中这一列由其他列计算而得。

例如，知道直角三角形的两条直角边，要求直角三角形的面积。很明显，面积可以通过两条直角边计算而得，那么，这时候就可以在数据库中只存放直角边，面积使用generated column，如下所示：

CREATE TABLE xttblog (sidea DOUBLE, sideb DOUBLE, area DOUBLE AS (sidea * sideb / 2));
insert into xttblog(sidea, sideb) values(3, 4);
select * from xttblog;
+-------+-------+------+
| sidea | sideb | area |
+-------+-------+------+
|     3 |     4 |    6 |
+-------+-------+------+

在MySQL 5.7中，支持两种generated column，即virtual generated column和stored generated column，前者只将generated column保存在数据字典中（表的元数据），并不会将这一列数据持久化到磁盘上；后者会将generated column持久化到磁盘上，而不是每次读取的时候计算所得。很明显，后者存放了可以通过已有数据计算而得的数据，需要更多的磁盘空间，与virtual column相比并没有优势。因此，在不指定generated column的类型时，默认是virtual column，如下所示：

show create table xttblog/G
*************************** 1. row ***************************
       Table: xttblog
Create Table: CREATE TABLE `xttblog` (
  `sidea` double DEFAULT NULL,
  `sideb` double DEFAULT NULL,
  `area` double GENERATED ALWAYS AS (((`sidea` * `sideb`) / 2)) VIRTUAL
) ENGINE=InnoDB DEFAULT CHARSET=utf-8

如果你觉得generate column提供的功能，也可以在用户代码里面实现，并没有什么了不起的地方，那么，或许还有一个功能能够吸引挑剔的你，那就是为generate column创建索引。在这个例子中，如果我们需要根据面积创建索引以加快查询，就无法在用户代码里面实现，使用generate column就变得非常简单：

alter table xttblog add index ix_area(area);

MySQL 5.7 新增 sys schema 特性。

Sys schema 是 MySQL 5.7.7 中引入的一个系统库，包含了一系列视图、函数和存储过程， 该项目专注于MySQL的易用性。例如，我们可以通过sys schema快速的知道，哪些语句使用了临时表，哪个用户请求了最多的io，哪个线程占用了最多的内存，哪些索引是无用索引等。

Sys schema 中包含了大量的视图，那么，这些视图的信息来自哪里呢？视图中的信息均来自 performance schema 统计信息。这里有一个很好的比喻：

For Linux users I like to compare performance_schema to /proc, and SYS to vmstat.

也就是说，performance schema提供了信息源，但是，没有很好的将这些信息组织成有用的信息，从而没有很好的发挥它们的作用。而sys schema使用performance schema信息，通过视图的方式给出解决实际问题的答案。
例如，下面这些问题，在MySQL 5.7之前，需要借助外部工具才能知道，在MySQL 5.7中，直接查询sys库下相应的表就能得到答案：如何查看数据库中的冗余索引。

select * from sys.schema_redundant_indexes;

如何获取未使用的索引。

select * from schema_unused_indexes;

如何查看使用全表扫描的SQL语句。

select * from statements_with_full_table_scans

MySQL 5.7为了支持online buffer pool resize，引入chunk的概念，每个chunk默认是128M，当我们在线修改buffer pool的时候，以chunk为单位进行增长或收缩。这个参数的引入，对innodb_buffer_pool_size的配置有了一定的影响。innodb要求buffer pool size是innodb_buffer_pool_chunk_size* innodb_buffer_pool_instances的倍数，如果不是，将会适当调大innodb_buffer_pool_size，以满足要求，因此，可能会出现buffer pool的实际分配比配置文件中指定的size要大的情况。

Online DDL MySQL 5.7支持重命名索引和修改varchar的大小，这两项操作在之前的版本中，都需要重建索引或表。

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);

在线开启GTID，在之前的版本中，由于不支持在线开启GTID，用户如果希望将低版本的数据库升级到支持GTID的数据库版本，需要先关闭数据库，再以GTID模式启动，所以导致升级起来特别麻烦。MySQL 5.7以后，这个问题不复存在。

性能一直都是用户最关心的问题，在MySQL每次新版本中，都会有不少性能提升。在MySQL 5.7中，性能相关的改进非常多，这里仅介绍部分改进，包括临时表相关的性能改进、只读事务的性能优化、连接建立速度的优化和复制性能的改进。

临时表的性能改进。MySQL 5.7 为了提高临时表相关的性能，对临时表相关的部分进行了大幅修改，包括引入新的临时表空间；对于临时表的DDL，不持久化相关表定义；对于临时表的DML，不写redo，关闭change buffer等。所有临时表的改动，都基于以下两个事实：

• 临时表只在当前会话中可见
• 临时表的生命周期是当前连接（MySQL宕机或重启，则当前连接结束）

也就是说，对于临时表的操作，不需要其他数据一样严格地进行一致性保证。通过不持久化元信息，避免写redo等方式，减少临时表操作的IO，以提高临时表操作的性能。

只读事务性能改进。众所周知，在传统的OLTP应用中，读操作远多于写操作，并且，读操作不会对数据库进行修改，如果是非锁定读，读操作也不需要进行加锁。因此，对只读事务进行优化，是一个不错的选择。

在MySQL 5.6中，已经对只读事务进行了许多优化。例如，将MySQL内部实现中的事务链表分为只读事务链表和普通事务链表，这样在创建ReadView的时候，需要遍历事务链表长度就会小很多。

在MySQL 5.7中，首先假设一个事务是一个只读事务，只有在该事务发起了修改操作时，才会将其转换为一个普通事务。MySQL 5.7通过避免为只读事务分配事务ID，不为只读事务分配回滚段，减少锁竞争等多种方式，优化了只读事务的开销，提高了数据库的整体性能。

加速连接处理。在MySQL 5.7之前，变量的初始化操作（THD、VIO）都是在连接接收线程里面完成的，现在将这些工作下发给工作线程，以减少连接接收线程的工作量，提高连接的处理速度。这个优化对那些频繁建立短连接的应用，将会非常有用。

复制性能的改进。MySQL的复制延迟是一直被诟病的问题之一，欣喜的是，MySQL 5.7版本已经支持”真正”的并行复制功能。MySQL 5.7并行复制的思想简单易懂，简而言之，就是”一个组提交的事务都是可以并行回放的”，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）。MySQL 5.7以后，复制延迟问题永不存在。

这里需要注意的是，为了兼容MySQL
5.6基于库的并行复制，5.7引入了新的变量slave-parallel-type，该变量可以配置成DATABASE（默认）或LOGICAL_CLOCK。可以看到，MySQL的默认配置是库级别的并行复制，为了充分发挥MySQL 5.7的并行复制的功能，我们需要将slave-parallel-type配置成LOGICAL_CLOCK。

参考资料

1. What’s New in MySQL 5.7
2. What Is New in MySQL 5.7
3. MySQL 5.7 并行复制实现原理与调优

： » DBA 必会的 MySQL 5.7 新特性