MySQL 5.7新特性概览-持续更新

MySQL 5.7 GA的发布，号称160万只读QPS，大有赶超NoSQL趋势。

上面这个图是Oracle在只读场景下官方测试的结果，看上去QPS确实提升很大。不过官方的硬件测试环境是很高的，所以这个160万QPS对于大家测试来说，可能还比较遥远，所以实际测试的结果可能会失望。但是，至少我们看到了基于同样测试环境，MySQL 5.7在性能上的改进，对于多核利用的改善。

MySQL 5.7新增特性介绍

一、Security improvements

初始化方式的改变及默认添加用户密码

MySQL默认的部署策略发生了变化，变得更加安全。mysql_install_db弃用了，改用mysqld加–initialize或–initialize-insecure选项来初始化数据目录。使用–initialize时，MySQL数据库初始化完成以后，会产生一个root@localhost用户，从MySQL 5.7开始，root用户的密码不再是空，而是随机产生一个密码，保存于error log，初次登录需使用密码并改变密码。这也导致了用户安装5.7时发现的与5.6版本比较大的一个不同点。

mysqld --initialize --user=mysql --datadir=/data/mysql

1	mysqld --initialize --user=mysql --datadir=/data/mysql

官方文档：http://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html

删除test库及不再创建匿名账号

MySQL官方已经删除了test数据库，默认安装完后是没有test数据库的，就算用户创建了test库，也可以对test库进行权限控制了，并且不再创建匿名账户。

mysql.user表的改变

mysql.user表新增plugin列，且若某账户该字段值为空则账户不能使用。从低版本MySQL升级至MySQL5.7时要注意该问题，且建议DBA将使用mysql_old_password插件的账户替换为使用mysql_native_password插件。另外默认的用户密码字段由Password变成了authentication_string。

增加密码过期策略

数据库管理员可以制定账户密码自动过期策略，密码过期后必须强制进行更改。

ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;

1	ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;

官方文档：http://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html

增加用户锁定限制

数据库管理员可以锁定/解锁账户来进行更好的登录控制，对应的，mysql.user表中新增account_locked列来表示锁定状态。版本升级过程中要注意该问题。

ALTER USER 'jeffrey'@'localhost' ACCOUNT LOCK;
ALTER USER 'jeffrey'@'localhost' ACCOUNT UNLOCK;

1 2	ALTER USER 'jeffrey'@'localhost' ACCOUNT LOCK; ALTER USER 'jeffrey'@'localhost' ACCOUNT UNLOCK;

官方文档：http://dev.mysql.com/doc/refman/5.7/en/account-locking.html

默认开启连接加密

MySQL可以自动创建SSL、RSA证书和Key文件来支持安全连接，但前提是Server用OpenSSL编译，默认情况下客户端是使用安全连接服务器的。

官方文档：http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-rsa-files-using-mysql.html

试验可见：MySQL 5.7客户端使用加密连接

增加密码复杂度检查插件validate_password

如果使用YUM安装MySQL的话，默认会装载这个插件，这个插件就是对用户密码复杂度（字母大小写、数字、特殊字符、密码长度等）的一个检查，如果不满足设定的复杂度要求则不允许创建用户。

试验可见：MySQL 5.7多方式安装

二、SQL mode changes

SQL_Mode变为STRICT_TRANS_TABLES SQL mode

SQL要求更严格，version < 5.6.6 sql_mode 为空，最为宽松，不够严谨。

5.6.6 < version < 5.7.4

NO_ENGINE_SUBSTITUTION

version > 5.7.9

ONLY_FULL_GROUP_BY

STRICT_TRANS_TABLES

NO_ZERO_IN_DATE

NO_ZERO_DATE

ERROR_FOR_DIVISION_BY_ZERO

NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION

以NO_ZERO_DATE为例，如果你原表里有0000-00-00 这种数据，在MySQL 5.7使用默认SQL_Mode时候改表时候就会报错了。

官方文档：http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-changes

试验可见：MySQL 5.7默认SQL模式带来的问题总结

三、Online ALTER TABLE

MySQL 5.7支持重命名索引和修改varchar的大小，无需table-copy。这两项操作在之前的版本中，都需要重建索引或表。适用于各引擎。

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

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

但存在限制，即只支持0~255字节内的或者255以上字节间的增加，也就是说若从254增到256时不能使用INPLACE算法，必须使用COPY算法，否侧报错。这是因为0~255内的VARCHAR值需要一个额外的字节来编码，而256以上的VARCHAR值需要两个字节来编码。另外使用INPLACE算法缩小VARCHAR的ALTER TABLE也是不支持的，必须用COPY算法。

官方文档：http://dev.mysql.com/doc/refman/5.7/en/alter-table.html

试验可见：MySQL InnoDB Online DDL

四、InnoDB enhancements.

支持动态修改Buffer Pool

从MySQL 5.7.5开始可以在线动态调整InnoDB Buffer Pool，对运维更友好。很多人都经历过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要大的情况。

MySQL redo log大小调整

5.5 <= 4G， 5.6 +<= 512G。当然这个也不是越大越好，但是提供了可以尝试的机会，越大的 redo log 理论会有更稳定的性能。当然带来的风险就是故障恢复时间会更长。下图就是不同 redo 大小的性能对比，主要是看性能抖动情况

Innodb_file_per_table

默认值Off <= 5.6.5 <=On，独立表空间优点很明显。尤其可以使用 InnoDB Transportable tablespaces，可以像MyISAM 一样快速迁移表。

Query cache

1<＝ 5.6.8 <= 0，默认关闭。整体来说关闭query cache是利远大于弊，官方最终也选择了关闭。query cache访问需要获取一个全局锁，高并发时候争用很严重。更主要的是query cache缓存的效果并不好。

binlog_rows_query_log_events

默认关闭，可选打开，建议打开，还是比较有用的。可以看到row格式下的sql语句，方便排查问题和恢复数据。开启binlog_rows_query_log_events参数后binlog格式如下：

# at 934
#160418 14:46:59 server id 11  end_log_pos 992 CRC32 0x930e3483         Rows_query
# update t1 set name='bb' where id=2
.......................
### UPDATE `mytest`.`t1`
### WHERE
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2='tt' /* VARSTRING(64) meta=64 nullable=1 is_null=0 */
### SET
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2='bb' /* VARSTRING(64) meta=64 nullable=1 is_null=0 */

# at 934

#160418 14:46:59 server id 11 end_log_pos 992 CRC32 0x930e3483 Rows_query

# update t1 set name='bb' where id=2

.......................

### UPDATE `mytest`.`t1`

### WHERE

### @1=2 /* INT meta=0 nullable=1 is_null=0 */

### @2='tt' /* VARSTRING(64) meta=64 nullable=1 is_null=0 */

### SET

### @1=2 /* INT meta=0 nullable=1 is_null=0 */

### @2='bb' /* VARSTRING(64) meta=64 nullable=1 is_null=0 */

可以看到逻辑SQL执行的语句了，但是这个SQL语句使用#号注释了，如”# update tl set name=’bb’ where id=2″。

max_execution_time

MySQL 5.7.4刚引入名字是max_statement_time，后来改成max_execution_time。单位是毫秒，SQL语句的超时中断，自我保护的一种方案。只针对select，也可以在sql里指定。如果percona版本的话，这个参数更暴力，对所有请求生效慎用。

Innodb_numa_interleave

建议关掉numa。最早Twitter开源分支里有提供，也可以启动实例时候设置numactl –interleave all，不过实际线上使用系统默认numa策略，并没有遇到过因为numa导致的swap问题。

InnoDB临时表的DDL性能提升

InnoDB临时表元数据不再存储于InnoDB系统表而是存储在INNODB_TEMP_TABLE_INFO，包含所有用户和系统创建的临时表信息。该表在第一次在其上运行select时被创建。

InnoDB现在支持MySQL-supported空间数据类型。也即，之前的空间数据是以binary BLOB数据存储的，现在空间数据类型被映射到了一个InnoDB内部数据类型DATA_GEOMETRY.

对于non-compressed InnoDB临时表有独立的表空间，表空间在每次服务器重启时于默认的DATADIR中被重建，可通过innodb_temp_data_file_path选项指定其他路径。

innochecksum (离线的InnoDB文件校验工具)，新增新的选择项或扩展的功能，如，可指定特定的校验算法、可以只重写校验值而不进行验证、可指定允许的校验和不匹配量、显示各类页的个数、导出页类型信息、输出至日志、从标准输入读取数据等。目前可支持超过2G的文件。(http://dev.mysql.com/doc/refman/5.7/en/innochecksum.html)

针对临时表及相关对象引入新的“non-redo” undo log，存放于临时表空间。该类型的undo log非 redolog 因为临时表不需崩溃恢复、也就无需redo logs，但却需要 undo log用于回滚、MVCC等。默认的临时表空间文件为ibtmp1，位于数据目录在每次服务器启动时被重新创建，可通过innodb_temp_data_file_path指定临时表空间。(http://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-table-undo-logs.html)

可通过innodb_buffer_pool_dump_pct调整buffer pool中最近使用的页读取并dump的百分比。当有其他InnoDB后台任务所引起的I/O活动时，可通过 innodb_io_capacity 限制各I/O活动包括 buffer pool load 操作的频次。

InnoDB支持full-text parser 插件(http://dev.mysql.com/doc/refman/5.7/en/full-text-plugins.html)

支持多page cleaner线程从buffer pool中刷脏页，通过 innodb_page_cleaners配置线程数，默认值为1.

支持使用INPLACE算法的online DDL语句重建普通表和分区表：OPTIMIZE TABLE、ALTER TABLE … FORCE、ALTER TABLE … ENGINE=INNODB。

Linux系统中Fusion-io Non-Volatile Memory (NVM)文件系统提供了原子写能力，使InnoDB双写变得冗余。因此，MySQL5.7.4以后，对于支持原子写的Fusion-io设备上的系统表空间InnoDB doublewrite buffer会自动关闭。

对于分区表和独立的InnoDB表分区从MySQL5.7.4开始支持“可传输”表空间，使得分区表的备份步骤更加容易也使得在不同MySQl实例间拷贝分区表和独立的表分许成为可能。(http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.html)

可通过 innodb_buffer_pool_size 参数动态调整buffer pool大小，resize以chunk为单位，chunk大小通过 innodb_buffer_pool_chunk_size配置，另可通过Innodb_buffer_pool_resize_status 状态变量观察调整过程。(http://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-online-resize.html)

MySQL5.7.5开始Multi-threaded page clean也在shutdown和recover阶段被支持。

MySQL5.7.5后支持空间数据类型上建索引。且可通过 ALTER TABLE … ADD SPATIAL INDEX ALGORITHM=INPLACE进行在线操作。

创建和重建索引时支持bulk load，该方法被称为“sorted index build”，提升了索引创建效率，支持全文索引但不支持空间索引。可通过innodb_fill_factor定义每个页的填充因子，剩余的空间用于将来的索引增长。(http://dev.mysql.com/doc/refman/5.7/en/sorted-index-builds.html)

使用新的日志记录类型(MLOG_FILE_NAME)来识别上一个检查点以来发生变化的表空间。这简化了崩溃恢复时的表空间发现，消除了redo log应用之前的文件系统扫描。 (http://dev.mysql.com/doc/refman/5.7/en/innodb-recovery-tablespace-discovery.html).需要注意的是这一行为导致了redo log格式的变化，所以升级至MySQL5.7.5或者从改版本降级时需完全关闭MySQL。

可通过配置 innodb_undo_log_truncate来truncate undo表空间中的undo logs。系统表空间内的undo logs不会被truncate。(默认情况下undo log存储于系统表空间，可通过innodb_undo_directory、 innodb_undo_logs、 innodb_undo_tablespaces进行调整。http://dev.mysql.com/doc/refman/5.7/en/truncate-undo-tablespace.html )

支持本地化分区(native partitioning),之前需依赖ha_partition handler为每个分区创建handler对象，现在只需一个partition-aware handler对象，节约了内存。（可通过mysql_upgrade或者ALTER TABLE … UPGRADE PARTITIONING将老方法建的分区表升级为新的）。

支持使用CREATE TABLESPACE语句创建通用表空间。并可以通过 CREATE TABLE tbl_name … TABLESPACE [=] tablespace_name 或者 ALTER TABLE tbl_name TABLESPACE [=] tablespace_name将表添加到创建的通用表空间。(http://dev.mysql.com/doc/refman/5.7/en/general-tablespaces.html)

可通过innodb_default_row_format指定InnoDB表的默认行格式，新版本的默认值有COMPACT替换为了DYNAMIC 。

五、Json Support

随着非结构化数据存储需求的持续增长，各种非结构化数据存储的数据库应运而生（如MongoDB）。从最新的数据库使用排行榜来看，MongoDB已经超过了PostgreSQL，其火热程度可见一斑。各大关系型数据库也不甘示弱，纷纷提供对JSON的支持，以应对非结构化数据库的挑战。MySQL数据库从5.7.8版本开始，也提供了对JSON的支持。不再以字符串形式存储而是以二进制格式存储，允许快速读取文档元素。JSON列在插入或更新时会自动进行验证，文档格式不正确会报错。除了可用常用比较操作符进行比较外还引入一系列函数用于处理JSON类型。（http://dev.mysql.com/doc/refman/5.7/en/json.html）

其使用方式如下：

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

1 2	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.能够提供完整的事务支持。

试验可见：MySQL 5.7新特性JSON格式支持

六、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   |
+-------+-------+------+

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

show create table triangle\G
*************************** 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

show create table triangle\G

*************************** 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);

1	alter table triangle add index ix_area(area);

试验可见：MySQL 5.7支持为表增加计算列

七、Performance improvements

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

临时表的性能改进

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

1. 临时表只在当前会话中可见。

2. 临时表的生命周期是当前连接（MySQL宕机或重启，则当前连接结束）。

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

只读事务性能改进

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

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

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

加速连接处理

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

八、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

包含sys库，存储从performance_schema收集用来辅助DBA和开发者的信息的相关对象，如，表和触发器、视图、存储过程、存储函数等，可用以调优和问题诊断。(http://dev.mysql.com/doc/refman/5.7/en/sys-schema.html)

九、Replication

replication info in tables

crash-safe slave方案，最早Google做的方案是存储在事务日志里。单独存储更灵活，可以解决很多从库宕机后duplicate key 问题。

动态修改复制过滤

支持在线设置复制的过滤规则，不再需要重启MySQL，只需要停止SQL thread，修改完成以后，启动SQL thread。

试验可见：MySQL主从复制过滤参数介绍

支持多源复制

开始支持多源复制也即从多个master向某一个salve复制。用于将多个server备份到单个server、合并表shard、从多个server合并数据到单个server等（目前不提供冲突检测和解决方案，交由应用层处理。http://dev.mysql.com/doc/refman/5.7/en/replication-multi-source.html）。

随多源复制而引入的另外一项技术为复制信道（replication channels），Replication channels使slave可以打开多个连接，每个信道连接至不同的master进行复制。(http://dev.mysql.com/doc/refman/5.7/en/replication-channels.html)

试验可见：MySQL 5.7多源复制实践

Group Replication Performance Schema tables

performance_schema中新增一批表提供复制组相关信息(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html)

Group Replication SQL

引入如下两条组复制控制语句：(http://dev.mysql.com/doc/refman/5.7/en/replication-group-sql.html)

START GROUP_REPLICATION

STOP GROUP_REPLICATION

支持在线开启GTID

在线开启GTID ，在之前的版本中，由于不支持在线开启GTID，用户如果希望将低版本的数据库升级到支持GTID的数据库版本，需要先关闭数据库，再以GTID模式启动，所以导致升级起来特别麻烦。MySQL 5.7以后，这个问题不复存在。当然也不是简单的SET @@GLOBAL.GTID_MODE = ON，步骤也是很复杂，不过至少不用停机，也是进步。

但是经过本人测试发现，至少目前还不是多么完美，并发大的情况下会导致数据丢失。

试验可见：MySQL 5.7在线把基于日志复制变更为GTID的复制

从库无须开启log_slave_updates

MySQL 5.7新增gtid_executed，避免GTID复制必须开启log_slave_updates。MySQL 5.6版本开启GTID模式，必须打开参数log_slave_updates，简单来说就是必须在从机上再记录一份二进制日志。这样的无论对性能还是存储的开销，无疑会相应的增大。而MySQL 5.7版本开始无需在GTID模式下启用参数log_slave_updates，其中最重要的原因在于5.7在mysql库下引入了新的表gtid_executed。通过引入gtid_executed表实现，对性能优一定帮助，大大简化切换流程。增强半同步复制，确保从库先收到，设置半同步从库个数。使用mysqlbinlog作为伪slave是个不错方案。

试验可见：MySQL 5.7新增gtid_executed，避免GTID复制必须开启log_slave_updates

基于表的并行复制技术

并行复制优化，MySQL 5.6默认并行复制。logical-clock 5.7引入，一个组提交内事务都可以并行，可以达到接近主库并发效果。

十、System and status variables.

http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

优先从performance_schema下的表中获取系统变量和状态变量信息（老版本从information_schema下的表中获取，这些表将来会被移除），这对show variables和show status语句也有影响，也即信息源来自于performance_schema。若想使用原来的表获取信息可开启show_compatibility_56 参数（不推荐，只作为升级过程中的辅助工具，将来会被移除）。(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-variable-table-migration.html)

十一、其他方面的改进

Optimizer

explain可以用来获取其他SESSION/CONNECTION中正在运行的语句的执行计划（前提条件是正在运行语句且语句类型支持EXPLAIN），语法为：EXPLAIN [options] FOR CONNECTION connection_id;其中connection_id即连接id，可由information_schema.processlist或者CONNECTION_ID()获取。
支持在语句中(以往是在optimizer_switch系统变量里)提供优化器提示信息以便于对语句的执行计划进行更还的控制。同样，在使用explain/desc查看执行计划时也可以在语句中使用优化提示，以便于查看优化提示是如何影响执行计划的。（http://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html）

Triggers

之前的版本每个表上对于某一触发事件(insert\update\delete)和触发时机（before\after）的组合只能有一个触发器，新版本取消了这一限制。比如：值之前的版本，创建了如下触发器后CREATE TRIGGER ins_sum BEFORE INSERT ON account FOR EACH ROW SET @sum = @sum + NEW.amount;不能在创建另外的基于 BEFORE INSERT ON account的触发器了，新版本可以，只要触发器不同名即可。

Logging

之前版本，Unix或类Unix系统上的MySQL支持将错误日志发送到syslog，具体是通过mysqld_safe捕获错误输出然后传递到syslog来实现的。新的版本原生支持将错误日志输出到syslog,且适用于windows系统，只需要通过简单的参数(log_syslog等)配置即可。（http://dev.mysql.com/doc/refman/5.7/en/error-log.html）

mysql支持–syslog选项，可将交互式的语句输出到系统的syslog中（Unix或类Unix系统下一般是/var/log/message）。对于匹配“ignore”过滤规则（可通过 –histignore选项或者 MYSQL_HISTIGNORE环境变量进行设置）的语句不会被记入。关于mysql客户端的日志使用参见：http://dev.mysql.com/doc/refman/5.7/en/mysql-logging.html

MySQL client

在Linux下，我们经常使用ctrl+c来终止一个命令的运行，在MySQL 5.7之前，如果用户输入了错误的SQL语句，按下ctrl+c ，虽然能够”结束”SQL语句的运行，但是，也会退出当前会话，MySQL 5.7对这一违反直觉的地方进行了改进，不再退出会话，用起来非常顺手。

Database name rewriting with mysqlbinlog

mysqlbinlog工具添加新的选项–rewrite-db，支持从行复制格式的二进制日志中读取事件时将数据库名重写 –rewrite-db=’dboldname->dbnewname’.可以通过指定多次该参数来指定多个重写规则。

HANDLER with partitioned tables

可以在分区表上使用HANDLER(http://dev.mysql.com/doc/refman/5.6/en/handler.html)

Index condition pushdown support for partitioned tables

使用InnoDB或者MyISAM的分区表上的查询支持使用ICP（http://dev.mysql.com/doc/refman/5.7/en/index-condition-pushdown-optimization.html）

WITHOUT VALIDATION support for ALTER TABLE … EXCHANGE PARTITION

ALTER TABLE … EXCHANGE PARTITION语句包含{WITH|WITHOUT} VALIDATION 从句，默认为WITH VALIDATION ，会逐行验证交换过来的值是否满足分区边界定义。若指定了WITHOUT VALIDATION则不进行验证。(http://dev.mysql.com/doc/refman/5.7/en/partitioning-management-exchange.html)

Master dump thread improvements

master dump thread进行了重构来减少锁争用提升master吞吐量。之前的版本中只要读取一个时间dump thread就要获取锁；MySQL5.7.2和后续版本中，只有从最近一次成功写入的事件末位位置读取时才会获取锁。这意味值多个dump threads可并发读取二进制日志，且可以在客户端向二进制日志写入时读取。

Globalization improvements

开始包含gb18030字符集，支持 China National Standard GB18030 字符集。

对分布式事务做了Bug修复和性能改进。

Changing the replication master without STOP SLAVE

新版本MySQL主从复制时在执行CHANGE MASTER TO语句前可不必执行 STOP SLAVE。此时，CHANGE MASTER语句的行为依赖于slave的SQL线程和IO线程；两个线程的启/停决定了某一时刻CHANGE MASTER TO语句中可以/不可以使用的选项。具体规则如下：

若SQL线程停止，则可在CHANGE MASTER TO语句中使用 RELAY_LOG_FILE,
RELAY_LOG_POS和MASTER_DELAY
选项的组合，即时是IO线程正在运行中也无妨。若此时IO线程还在运行则不能运行除上述选项之外的选项。
若IO线程停止，则可以在CHANGE MASTER TO语句中使用除了RELAY_LOG_FILE,
RELAY_LOG_POS和MASTER_DELAY 选项之外的任何选项的组合，即时是SQL线程正在运行也无妨。
在运行CHANGE MASTER TO…MASTER_AUTO_POSITION=1之前SQL线程和IO线程必须停止。

可通过 SHOW SLAVE STATUS命令检查SQL线程和IO线程运行状态。
之前的版本中若使用基于语句的复制且有临时表那么在执行STOP SLVAVE后执行CHANGE MASTER TO可能在远slave上留下临时表。新版本中会给出警告，如果在执行CHANGE MASTER TO使Slave_open_temp_tables 仍为0.

废弃特性

如下特性在MySQL5.7中不推荐使用，可能在将来的版本中被移除：
ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE和NO_ZERO_IN_DATE几个sql mode不赞成使用了（但目前默认开启），长远的计划是将这个mode包含进 strict mode而明确移除这几个单独的mode。
关于账户管理语句有一下不赞成再使用的特性：

不推荐使用GRANT语句创建用户，而推荐使用CREATE USER语句创建。这样一来NO_AUTO_CREATE_USER这一sql mode对于GRANT语句也就没什么意义了，所以也将降级。

不推荐使用GRANT语句修改账户属性，而仅用于账户赋权。账户属性通过CREATE USER或者ALTER USER在创建或修改时赋予或者改动；

不推荐使用IDENTIFIED BY PASSWORD ‘hash_string’ 语法，推荐使用IDENTIFIED WITH auth_plugin AS ‘hash_string’ ；

不推荐使用SET PASSWORD语句和PASSWORD()函数，而推荐使用ALTER USER来修改账户密码；

不推荐使用old_password系统变量。

不推荐使用GROUP BY隐式排序，推荐明确使用ORDER BY从句。（GROUP BY排序只是MySQL的扩展语法，可能在将来版本移除）

不推荐使在EXPLAIN语句中使用EXTENDED和PARTITIONS关键字（仍可被识别但在新版本中已不必要。）
–skip-innodb以及–innodb=OFF, –disable-innodb等不赞成使用，因为新版本中InnoDB不能能被禁止了。

不推荐使用log_warnings系统变量和–log_warnings选项，推荐使用 log_error_verbosity 。

binlog_max_flush_queue_time 在新版本中已失效。

innodb_support_xa 在新版本中无效，因为XA事务的两阶段提交在MySQL5.7中默认支持。

metadata_locks_cache_size和metadata_locks_hash_instances、sync_frm、 character_set_database、collation_database系统变量不再起作用。

ENCRYPT(), ENCODE(), DECODE(), DES_ENCRYPT()和DES_DECRYPT() 不推荐使用，建议使用 AES_ENCRYPT() 和 AES_DECRYPT()。

请使用MBREquals()替代MBREqual()。

请使用Performance Schema替代INFORMATION_SCHEMA.PROFILING。

请使用原生的syslog替代mysqld_safe支持的syslog输出。

mysqlcheck工具的–fix-db-names和–fix-table-names选项不推荐使用，以及ALTER DATABASE语句的UPGRADE DATA DIRECTORY NAME从句不推荐使用。

移除特性

对pre-4.1版本的密码hash格式的支持被移除，相关联的，old_passwords系统变量、 OLD_PASSWORD()函数被移除，mysql_old_password认证插件被移除，–secure-auth选项无效且将在后续版本移除、 secure_auth 变量值允许为1，–skip-secure-auth被移除。

YEAR(2)不再被支持，请使用YEAR(4).

innodb_mirrored_log_groups被移除。

使用default_storage_engine代替storage_engine。

thread_concurrency、timed_mutexes 系统变量。

ALTER TABLE的IGNORE从句。

INSERT DELAYED 、 REPLACE DELAYED 中的DELAYED会被忽略，相关联的mysqldump中的–delayed-insert 选项被移除，performance_schema.table_lock_waits_summary_by_table中相关列被移除，mysqlbinlog不再为INSERT DELAYED注解。

Windows系统中使用.sys文件的Database symlinking被移除而使用支持native symlink 的mylink。(http://dev.mysql.com/doc/refman/5.7/en/windows-symbolic-links.html)

mysql_upgrade中的–basedir, –datadir 和–tmpdir 选项。
选项前缀不再被支持，只支持使用选项全名，比如要用–key-buffer-size而不能用–key-buffer，还有–skip-grant-tables与–skip-grant等。

SHOW ENGINE INNODB MUTEX输出被移除，可通过Performance Schema表上创建视图获取相关信息。

InnoDB表空间监控和InnoDB表监控被移除。表监控信息可通过INFORMATION_SCHEMA表获取。

用于启用和禁用InnoDB Monitor以及InnoDB Lock Monitor的特殊命名的表被移除，由 innodb_status_output和innodb_status_output_locks两个动态的系统变量取代.（http://dev.mysql.com/doc/refman/5.7/en/innodb-monitors.html）

innodb_use_sys_malloc 和 innodb_additional_mem_pool_size 系统变量移除。

msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, mysql_waitpid, mysql_zap, mysqlaccess和mysqlbug 移除。

mysqlhotcopy被移除，可以使用mysqldump和 MySQL Enterprise Backup或者一些开源工具。

binary-configure.sh脚本被移除。

INNODB_PAGE_ATOMIC_REF_COUNT CMake选项被移除

innodb_create_intrinsic选项、 innodb_optimize_point_storage 、innodb_log_checksum_algorithm 选项被移除。

如果您觉得本站对你有帮助，那么可以支付宝扫码捐助以帮助本站更好地发展，在此谢过。