MySQL5.7介绍
身处 MySQL 这个圈子，能够切身地感受到大家对 MySQL 5.7 的期待和热情，似乎每个人都迫不及待的想要了解、学习和使用 MySQL 5.7。那么，我们不禁要问， MySQL 5.7 到底做了哪些改进，引入了哪些新功能，
性能又提升了多少，能够让大家翘首以盼，甚至欢呼雀跃呢？
下面就跟随我来一起了解一下 MySQL 5.7 的部分新功能。想要在一篇文章中介绍完 MySQL 5.7 的所有改进，几乎是不可能的。所以，我会选择一些有特别意思的、特别有用的功能进行介绍。希望通过这篇文章，能
够激发大家对 MySQL 5.7 的学习兴趣，甚至能够吸引大家将自己的业务迁移到 MySQL 5.7 上。
MySQL 5.7 的新特性
这一节中，将依次介绍 MySQL 5.7 的各种新特性。由于 MySQL 5.7 改进较多，因此，本文将这些新特性进行了简单的分类，分为安全性、灵活性、易用性、可用性和性能。接下来，将从各个分类依次进行介绍。
1. 安全性
安全性是数据库永恒的话题，在 MySQL 5.7 中，有不少安全性相关的改进。
包括：
1.MySQL 数据库初始化完成以后，会产生一个 root@localhost 用户，从 MySQL 5.7 开始， root 用户的密码不再是空，而是随机产生一个密码，这也导致了用户安装 5.7 时发现的与 5.6 版本比较大的一个不同点.
2.MySQL 官方已经删除了 test 数据库，默认安装完后是没有 test 数据库的，就算用户创建了 test 库，也可以对 test 库进行权限控制了
3.MySQL 5.7 版本提供了更为简单 SSL 安全访问配置，并且默认连接就采用 SSL 的加密方式. 可以为用户设置密码过期策略，一定时间以后，强制用户修改密码
ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
可以”锁”住用户，用以暂时禁用某个用户
ALTER USER 'jeffrey'@'localhost' ACCOUNT LOCK;
ALTER USER l 'jeffrey'@'localhost' ACCOUNT UNLOCK;
2. 灵活性
MySQL 5.7 的两个全新的功能，即 JSON 和 generate column。充分使用这两个功能，能够极大地提高数据存储的灵活性。
2.1 JSON
随着非结构化数据存储需求的持续增长，各种非结构化数据存储的数据库应运而生（如 MongoDB）。从最新的数据库使用 排行榜 来看， MongoDB 已经超过了 PostgreSQL，其火热程度可见一斑。
各大关系型数据库也不甘示弱，纷纷提供对 JSON 的支持，以应对非结构化数据库的挑战。 MySQL 数据库从 5.7.8 版本开始，也提供了对 JSON 的支持。其使用方式如下：
CREATE TABLE t1 (jdoc JSON);
INSERT INTO t1 VALUES('{"key1": "value1", "key2": "value2"}');
MySQL 对支持 JSON 的做法是，在 server 层提供了一堆便于操作 JSON 的函数，至于存储，就是简单地将 JSON编码成 BLOB，然后交由存储引擎层进行处理，也就是说， MySQL 5.7 的 JSON 支持与存储引擎没有关系，
MyISAM 存储引擎也支持 JSON 格式。
MySQL 支持 JSON 以后，总是避免不了拿来与 MongoDB 进行一些比较。但是， MySQL 对 JSON 的支持，至少有两点能够完胜 MongoDB：
1.可以混合存储结构化数据和非结构化数据，同时拥有关系型数据库和非关系型数据库的优点
2.能够提供完整的事务支持
2.2 generate column
generated column 是 MySQL 5.7 引入的新特性，所谓 generated column，就是数据库中这一列由其他列计算而得。
例如，知道直角三角形的两条直角边，要求直角三角形的面积。很明显，面积可以通过两条直角边计算而得，那么，这时候就可以在数据库中只存放直角边，面积使用 generated column，如下所示：
CREATE TABLE triangle (sidea DOUBLE, sideb DOUBLE, area DOUBLE AS (sidea * sideb / 2));
insert into triangle(sidea, sideb) values(3, 4);
select * from triangle;
+-------+-------+------+
| sidea | sideb | area |
+-------+-------+------+
| 3 | 4 | 6 |
+-------+-------+------+
在 MySQL 5.7 中，支持两种 generated column，即 virtual generated column 和 stored generated column
virtual generated column前者只将 generated column 保存在数据字典中（表的元数据），并不会将这一列数 据持久化到磁盘上；
stored generated column 会将 generated column 持久化到磁盘上，而不是每次读取的时候计算所得。很明显，后者存放了可以通过已有数据计算而得的数据，需要更多的磁盘空间，与 virtual column 相比并没有优势。
因此，在不指定 generatedcolumn 的类型时，默认是 virtual column，如下所示：
show create table triangleG
*************************** 1. row ***************************
Table: triangle
Create Table: CREATE TABLE `triangle` (
`sidea` double DEFAULT NULL,
`sideb` double DEFAULT NULL,
`area` double GENERATED ALWAYS AS (((`sidea` * `sideb`) / 2)) VIRTUAL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
如果读者觉得 generate column 提供的功能，也可以在用户代码里面实现，并没有什么了不起的地方，那么,或许还有一个功能能够吸引挑剔的你，那就是为 generate column 创建索引。在这个例子中，如果我们需要
根据面积创建索引以加快查询，就无法在用户代码里面实现，使用 generate column 就变得非常简单：
alter table triangle add index ix_area(area);
3 易用性
易用性是数据库永恒的话题， MySQL 也在持续不断地提高数据库的易用性。在 MySQL 5.7 中，有很多易用性方面的改进，小到一个客户端快捷键 ctrl+c 的使用，大到专门提供一个系统库(sys)来帮助 DBA 和开发人
员使用数据库。 将重点介绍 MySQL 5.7 引入的 sys 库。
在 linux 下，我们经常使用 ctrl+c 来终止一个命令的运行，在 MySQL 5.7 之前，如果用户输入了错误的SQL 语句，按下 ctrl+c ，虽然能够”结束” SQL 语句的运行，但是，也会退出当前会话， MySQL 5.7 对这一
违反直觉的地方进行了改进，不再退出会话。
MySQL 5.7 可以 explain 一个正在运行的 SQL，这对于 DBA 分析运行时间较长的语句将会非常有用.
在 MySQL 5.7 中， performance_schema 提供了更多监控信息，包括内存使用， MDL 锁，存储过程等
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
4 可用性
MySQL 5.7 在可用性方面的改进也带给人不少惊喜。这里介绍特别有用的几项改进，包括：
-
在线设置 复制的过滤规则 不再需要重启 MySQL，只需要停止 SQL thread，修改完成以后，启动 SQL thread在线修改 buffer pool 的大小
-
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
以后，这个问题不复存在
5 性能
性能一直都是用户最关心的问题，在 MySQL 每次新版本中，都会有不少性能提升。在 MySQL 5.7 中，性能相关的改进非常多，这里仅介绍部分改进，包括临时表相关的性能改进、只读事务的性能优化、连接建立
速度的优化和复制性能的改进。
5.1 临时表的性能改进
MySQL 5.7 为了提高临时表相关的性能，对临时表相关的部分进行了大幅修改，包括引入新的临时表空间；对于临时表的 DDL，不持久化相关表定义；对于临时表的 DML，不写 redo， 关闭 change buffer 等。所有临
时表的改动，都基于以下两个事实 ：
1.临时表只在当前会话中可见
2.临时表的生命周期是当前连接（ MySQL 宕机或重启，则当前连接结束）
也就是说，对于临时表的操作，不需要其他数据一样严格地进行一致性保证。通过不持久化元信息，避免写 redo 等方式，减少临时表操作的 IO，以提高临时表操作的性能。
5.2 只读事务性能改进
众所周知，在传统的 OLTP 应用中，读操作远多于写操作，并且，读操作不会对数据库进行修改，如果是非锁定读，读操作也不需要进行加锁。因此，对只读事务进行优化，是一个不错的选择。
在 MySQL 5.6 中，已经对只读事务进行了许多优化。例如，将 MySQL 内部实现中的事务链表分为只读事务链表和普通事务链表，这样在创建 ReadView 的时候，需要遍历事务链表长度就会小很多。
在 MySQL 5.7 中，首先假设一个事务是一个只读事务，只有在该事务发起了修改操作时，才会将其转换为一个普通事务。 MySQL 5.7 通过 避免为只读事务分配事务 ID ，不为只读事务分配回滚段，减少锁竞争等
多种方式，优化了只读事务的开销，提高了数据库的整体性能。
5.3 加速连接处理
在 MySQL 5.7 之前，变量的初始化操作（ THD、 VIO）都是在连接接收线程里面完成的，现在将这些工作下发给工作线程，以减少连接接收线程的工作量，提高连接的处理速度。这个优化对那些频繁建立短连接的
应用，将会非常有用。
5.4 复制性能的改进
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。
6.总结
MySQL 5.7 确实带来了很多激动人心的功能，我们甚至不需要进行任何修改，只需要将业务迁移到 MySQL 5.7 上，就能带来不少性能的提升。
虽然 MySQL 5.7 在易用性上有了很多的改进，但是，也有不少需要注意的地方， 例如：
-
在设置 innodb 的 buffer pool 时，需要注意 chunk 的存在，合理设置 buffer pool instance 否则可能出
现实际分配的 buffer pool size 比预想的大很多的情况； -
多线程复制需要注意将 slave_parallel_type 设置为
LOGICAL_CLOCK，否则， MySQL 使用的是库级别的并行复制，对于大多数应用，并没有什么效果。