What Is New in MySQL 5.7之新特性篇

文档地址：
https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html#mysql-nutshell-additions

MySQL 5.7新增加的特性

以下特性已经被添加到MySQL 5.7：

l 安全性改进。
添加了这些安全改进：

Ø 服务器现在要求“mysql.user”系统表里的账户记录行有一个非空“plugin”字段值来禁用空值账户。关于服务器更新介绍，参考Section 2.11.1.1, “Changes Affecting Upgrades to MySQL 5.7”。由于对“mysql_old_password”的支持已经被移除，建议DBA们同样修改使用“mysql_old_password”插件认证的账户来使用“mysql_native_password”。关于账户更新介绍，参考Section 6.5.1.3, “Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin”。

Ø MySQL现在允许数据库管理员建立一个自动密码到期策略：任何通过账户连接到该服务器的用户，账户密码超过有效期后必须修改密码。更多信息参考Section 6.3.6, “Password Expiration Policy”。

Ø 为了更好地控制登录，管理员可以锁定和解锁账户。更多信息参考Section 6.3.10, “User Account Locking”。

Ø 为了方便地支持安全连接，使用OpenSSL编译的MySQL服务器在启动的时候可以自动生成缺失的SSL和RSA证书以及key文件。参考Section 6.4.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”。

无论是否使用OpenSSL和yaSSL编译，即使没有明确地配置使用SSL，一旦在数据目录中找到必要的SSL文件，服务器启动的时候自动尝试提供SSL。参考Section 6.4.4, “Configuring MySQL to Use Secure Connections”。

此外，MySQL发布包内置了一个可以手动调用来创建SSL和RSA key以及证书文件的功能mysql_ssl_rsa_setup。更多信息参考Section 4.4.5, “mysql_ssl_rsa_setup — Create SSL/RSA Files”。

Ø 默认情况下使用mysqld --initialize安装的MySQL部署是安全的。以下改进已经实现，用来作为默认部署特征：

①安装进程只创建一个root账户'root'@'localhost'，自动地给该账户生成一个随机密码以及标记该密码过期。MySQL管理员必须使用该随机密码以root账户连接以及分配一个新密码。（服务器把该随机密码写进错误日志。）
②安装不创建匿名用户账户。
③安装不创建“test”数据库。

更多信息参考Section 2.10.1.1, “Initializing the Data Directory Manually Using mysqld”。

l SQL mode改动。
事务型存储引擎（STRICT_TRANS_TABLES）现在默认启用strict SQL mode。

ONLY_FULL_GROUP_BY SQL mode的实施变得更加优化，不再排斥先前会被拒绝的确定性查询。因此，该模式现在默认启用，仅防止包含在一个组内不能保证唯一性的表达式的非确定性查询。

ERROR_FOR_DIVISION_BY_ZERO、NO_ZERO_DATE以及NO_ZERO_IN_DATE SQL modes虽然默认启用但是现在已经废弃了。长远计划是把它们囊括进strict SQL mode然后由于显示模式在未来的MySQL发行中移除它们。参考SQL Mode Changes in MySQL 5.7。

默认的系统变量sql_mode结果值变为以下SQL mode默认启动：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。

l Online ALTER TABLE。
ALTER TABLE现在支持一个可以重命名索引的RENAME INDEX语法。该改动原地工作而不需要一次表拷贝操作。它作用于所有的存储引擎。参考Section 13.1.8, “ALTER TABLE Syntax”。

l Ngram和MeCab full-text 解析插件。
MySQL提供一个内建的支持汉语、日语和韩语的full-text ngram解析插件以及一个支持日语的可安装的MeCab full-text解析插件。

更多信息参考Section 12.9.8, “ngram Full-Text Parser”和Section 12.9.9, “MeCab Full-Text Parser Plugin”。

l InnoDB改进。
添加了这些InnoDB改进：

Ø 原地使用ALTER TABLE，VARCHAR的大小可以被增大，正如这个例子：

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

只要一个VARCHAR字段需要的字节宽度保持一致即可。对于取值在0到255的VARCHAR，需要一个宽度的字节来编码。对于取值在256及更多的VARCHAR，需要两个宽度的字节来编码。 因此，原地ALTER TABLE仅支持增大VARCHAR的大小介于0到255字节间或者基于一个大于等于256字节值。

原地ALTER TABLE不支持从小于256字节值到大于等于256字节值增大VARCHAR。在这种情况下，即只能借助表拷贝（ALGORITHM=COPY），所需要的字节宽度可以从1修改到2。例如，通过原地使用ALTER TABLE去尝试把VARCHAR字段大小从255修改到256将返回一个报错：

ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change
column type INPLACE. Try ALGORITHM=COPY.

不支持使用原地ALTER TABLE减小VARCHAR大小。减小VARCHAR大小需要表拷贝（ALGORITHM=COPY）。

Ø 通过CREATE TABLE、DROP TABLE、TRUNCATE TABLE以及ALTER TABLE等语句优化，InnoDB临时表的DDL性能得到改进。

Ø InnoDB临时表的元数据不再储存至InnoDB系统表里面。作为替代，一张新表“INNODB_TEMP_TABLE_INFO”提供给用户一份当前有效临时表的快照。该表包含给定的InnoDB实例中所有有效的用户和系统创建的临时表的元数据和报告。当第一个SELECT语句触发它时，该表创建。

Ø InnoDB现在支持MySQL原生的空间数据类型。在旧的版本中，InnoDB将空间数据存储为二进制的BLOB数据。BLOB属于底层的基本数据类型，但是现在空间数据类型被映射为一种新的InnoDB内部的数据类型“DATA_GEOMETRY”。

Ø 对于所有非压缩的InnoDB临时表，现在有一个独立表空间。这个新的表空间总会在服务器启动的时候重新创建，默认位于数据目录下。一个新添加的文件配置选项参数，innodb_temp_data_file_path，接受一个用户自定义的临时表数据文件存放路径。

Ø innochecksum工具通过若干新选项和扩展功能被增强。参考Section 4.6.1, “innochecksum — Offline InnoDB File Checksum Utility”。

Ø 对于常规的和压缩过的临时表及相关对象，现在有一种新型的非redo的undo log存放于临时表空间。更多信息参考Section 14.4.12.1, “InnoDB Temporary Table Undo Logs”。

Ø InnoDB buffer pool的dump和load操作被增强。一个新的系统变量innodb_buffer_pool_dump_pct，允许你指定每个buffer pool中用于读出和dump的最近使用页百分比。当InnoDB后台任务有其他的I/O活动要执行时，InnoDB尝试使用innodb_io_capacity设置来限制每秒buffer pool的load操作数量。

Ø InnoDB添加对full-text解析器插件的支持。关于full-text解析器插件的更多信息参考Full-Text Parser Plugins以及Section 28.2.4.4, “Writing Full-Text Parser Plugins”。

Ø InnoDB支持多个page cleaner thread去刷新buffer pool中的脏页。一个新的系统变量“innodb_page_cleaners”用于指定page cleaner thread的数量。默认值“1”保持之前的配置，即只有一个page cleaner thread。该改进建立在已经于MySQL 5.6中完整实现的操作，其引进了一个单独的page cleaner thread来分担InnoDB master thread刷新buffer pool脏页的工作。

Ø 对于常规的和分区的InnoDB表的以下操作，扩展了Online DDL支持：
OPTIMIZE TABLE

ALTER TABLE ... FORCE

ALTER TABLE ... ENGINE=INNODB（当在一张InnoDB表上执行的时候）

Online DDL支持减少了表重建的时间并允许并发DML操作。参考Section 14.13.1, “Online DDL Overview”。

Ø Linux平台的Fusion-io Non-Volatile Memory（NVM）文件系统提供atomic写性能，这使得InnoDB的doublewrite buffer变得多余。The InnoDB doublewrite buffer is automatically disabled for system tablespace files 对系统表空间文件（ibdata files）存放于支持原子写的Fusion-io设备，InnoDB自动禁用doublewrite buffer。

Ø 对于分区的InnoDB表及其各自的InnoDB表分区，InnoDB支持Transportable Tablespace特性。该改进缓解了分区表的备份进程，使得各个MySQL实例间的分区表及其各自的表分区得以拷贝。更多额外信息参考Section 14.7.6, “Copying File-Per-Table Tablespaces to Another Instance”。

Ø innodb_buffer_pool_size参数是动态的，允许你不需要重启服务器就可以调整buffer pool的大小。因为牵涉到移动页到内存中一个新的位置，该修改操作按块执行。使用新的innodb_buffer_pool_chunk_size配置选项，块大小是可配置的。使用新的Innodb_buffer_pool_resize_status状态变量，你可以监控调整过程的进展情况。更多信息参考Configuring InnoDB Buffer Pool Size Online。

Ø 多线程page cleaner支持（innodb_page_cleaners）扩展到关闭和恢复两个阶段。

Ø InnoDB支持使用SPATIAL index索引空间数据类型，包括使用ALTER TABLE ... ALGORITHM=INPLACE进行在线操作（ADD SPATIAL INDEX）。

Ø 创建或者重建索引的时候InnoDB执行大块load。这种索引创建方式被称为“sorted index build”。这种提高索引创建效率的改进也被应用于full-text索引。一个新的全局配置选项innodb_fill_factor定义了“sorted index build”过程中每个页填充数据的空间百分比，剩下的空间留作以后索引增长使用。更多信息参考Section 14.8.12, “Sorted Index Builds”。

Ø 一个新的log记录类型（MLOG_FILE_NAME）用来标识自上一个checkpoint以来被修改的表空间。该改进简化了崩溃恢复时的表空间发现，消除了先于redo log请求的文件系统扫描。关于该改进意义的更多信息参考Tablespace Discovery During Crash Recovery。

该改进改变了redo log的格式，MySQL 5.7.5以前，在升级或者降级之前需要完全关闭MySQL。

Ø 你可以截断位于undo表空间的undo log。使用innodb_undo_log_truncate配置选项启用该特性。更多信息参考Section 14.7.8, “Truncating Undo Logs That Reside in Undo Tablespaces”。

Ø InnoDB支持原生分区。以前，InnoDB依赖于为每个分区创建一个handler对象的“ha_partition” handler。在原生分区下，一个分区的InnoDB表使用一个单独的“partition-aware” handler对象。该改进减少了InnoDB分区表对内存大小的需求。

自MySQL 5.7.9开始，mysql_upgrade查找和尝试升级使用“ha_partition”handler创建的InnoDB分区表。与此同时，在MySQL 5.7.9以及之后的版本，你可以在mysql客户端使用ALTER TABLE ... UPGRADE PARTITIONING按表名升级这种表。

Ø InnoDB支持使用CREATE TABLESPACE语法创建一般表空间。

CREATE TABLESPACE `tablespace_name`
  ADD DATAFILE 'file_name.ibd'
  [FILE_BLOCK_SIZE = n]

一般表空间可以创建在MySQL数据目录之外，有能力容纳多个表，支持所有的行格式表。

添加表到一般表空间使用CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name或者ALTER TABLE tbl_name TABLESPACE [=] tablespace_name语法。

更多信息参考Section 14.7.9, “InnoDB General Tablespaces”。

Ø DYNAMIC代替COMPACT成为InnoDB表隐式的默认行格式。一个新的配置选项innodb_default_row_format，指定默认的InnoDB行格式。更多信息参考Section 14.11.2, “Specifying the Row Format for a Table”。

Ø 从MySQL 5.7.11起，InnoDB支持对单一表空间（file-per-table）实施“data-at-rest”加密。创建或者更改一张InnoDB表的时候通过指定“ENCRYPTION”选项启用加密。该特性被称为InnoDB表空间加密，依赖于一个进行密匙管理的密钥环插件更多信息参考Section 6.5.4, “The MySQL Keyring”以及Section 14.7.10, “InnoDB Tablespace Encryption”。

l JSON支持。
从MySQL 5.7.8版本开始，MySQL支持一种原生的JSON类型。JSON值不以字符串的形式存储，取而代之的是一种允许访问文档元素快速读取的内置二进制格式。无论插入还是更新的时候，以JSON键存储的JSON文档自动进行验证，无效的文档产生报错。JSON文档标准化创建，可以使用所有的比较符进行比较，例如=、<、<=、>、>=、<>、!=、以及<=>；关于比较JSON值的时候支持的操作符和它们之间的优先级以及MySQL遵循的其他规则，参考 Comparison and Ordering of JSON Values。

MySQL 5.7.8同时也引进了一批操作JSON值的函数。这些函数包括列在这里的这些：

Ø 创建JSON值的函数：JSON_ARRAY()，JSON_MERGE()和JSON_OBJECT()。参考Section 12.16.2, “Functions That Create JSON Values”。

Ø 查询JSON值的函数：JSON_CONTAINS()，JSON_CONTAINS_PATH()，JSON_EXTRACT()，JSON_KEYS()和JSON_SEARCH()。参考Section 12.16.3, “Functions That Search JSON Values”。

Ø 修改JSON值的函数：JSON_APPEND()，JSON_ARRAY_APPEND()，JSON_ARRAY_INSERT()，JSON_INSERT()，JSON_QUOTE()，JSON_REMOVE()，JSON_REPLACE()，JSON_SET()和JSON_UNQUOTE()。参考Section 12.16.4, “Functions That Modify JSON Values”。

Ø 提供JSON值信息的函数：JSON_DEPTH()，JSON_LENGTH()，JSON_TYPE()和and JSON_VALID()。参考Section 12.16.5, “Functions That Return JSON Value Attributes”。

在MySQL 5.7.9以及之后的版本，你可以使用column->path作为JSON_EXTRACT(column, path)的简写。该写法作为键别名可以在SQL语句中一个字段标识符可以出现的任何地方工作，包括WHERE，ORDER BY，以及GROUP BY子句。也包括SELECT，UPDATE，DELETE，CREATE TABLE，以及其他的SQL语句。左边的必须是一个JSON键标识符（并且不是别名）。右边是一个用来解析JSON文档返回键值的逗点分割的JSON路径表达式。

参考Section 12.16.3, “Functions That Search JSON Values”获取更多关于“->”和“JSON_EXTRACT()”的信息。关于MySQL 5.7支持的JSON路径的信息，参考Searching and Modifying JSON Values。也请参考Indexing a Generated Column to Provide a JSON Column Index。

l 系统和状态变量。
系统和状态变量信息现在可以在“Performance Schema”表里面查找到，优先于“INFORMATION_SCHEMA”表来获取这些变量。这同时也影响到了SHOW VARIABLES和SHOW STATUS语句的操作。show_compatibility_56系统变量的值影响结果取自于何处的输出以及系统和状态变量语句及表所需要的权限。详情参考当前变量说明Section 5.1.5, “Server System Variables”。

注意
show_compatibility_56的默认值是“OFF”。在迁移到系统和状态变量新的运行方式以前，需要5.6运行方式的应用应该将这个变量设为“ON”。参考Section 25.19, “Migrating to Performance Schema System and Status Variable Tables”

l Sys库。
MySQL发行版现在包含sys库，这是一系列帮助DBA和开发者们理解“Performance Schema”收集的数据的对象。sys库的对象可以被用在典型调试和诊断的情况下。更多信息参考Chapter 26, MySQL sys Schema。

l 状况处理。
MySQL现在支持堆叠诊断区域。当堆叠的诊断区域被推出，第一个（当前的）诊断区域变成第二个（堆积的）诊断区域，一个新的当前诊断区域作为它的拷贝被创建。一个状况处理程序里，在执行语句改变新的当前诊断区域，但是GET STACKED DIAGNOSTICS可以被用来检测包含了导致处理程序被激活的状况信息的堆叠诊断区域，独立于包含处理程序自身的当前状况。（以前，存在一个单独的诊断区域。为了检测一个处理程序里程序激活的条件，执行任何可以改变它的语句之前必须检查这个诊断区域。）参考Section 13.6.7.3, “GET DIAGNOSTICS Syntax”以及Section 13.6.7.7, “The MySQL Diagnostics Area”。

l 优化器。
添加了以下优化器改进：

Ø EXPLAIN可以获取到在指定连接中执行的可解释语句的执行计划：

EXPLAIN [options] FOR CONNECTION connection_id;

更多信息参考Section 8.8.4, “Obtaining Execution Plan Information for a Named Connection”。

Ø 可能的话在独特的SQL语句中为优化器提供提示，相比通过optimizer_switch 系统变量实现，这提供了对语句执行计划更精细的控制。提示也是允许出现在使用EXPLAIN的语句中，让你能够查看提示是如何影响执行计划的。更多信息参考Section 8.9.2, “Optimizer Hints”。

l 触发器。
以前，对于触发器事件（INSERT，UPDATE，DELETE）和作用时间（BEFORE，AFTER）的每次关联，一张表至多只能有一个触发器。这个限制已经被挂起和允许单表多触发器。更多信息参考Section 23.3, “Using Triggers”。

l 登录。
添加了以下登录改进：

Ø 以前，在Unix和类Unix系统上，MySQL对于发送数据库错误日志到系统日志的支持，是通过捕捉mysqld_safe的抛错然后传到系统日志的形式。现在数据库服务器内置了原生的系统日志支持，并且已经扩展到包含对Windows系统的支持。关于把数据库错误日志输出发送到系统日志的更多信息参考Section 5.4.2, “The Error Log”。

Ø mysql客户端现在有一个启动交互式声明被发送到系统日志功能的--syslog选项。匹配到默认的“ignore”模式列表（"*IDENTIFIED*:*PASSWORD*"）的声明，以及匹配任何通过--histignore选项指定的模式的声明，登录将被拒绝。参考Section 4.5.1.3, “mysql Logging”。

l 生成列。
MySQL现在支持CREATE TABLE和ALTER TABLE语句中生成列的规范。生成列的值计算自字段创建的时候指定的一个表达式。生成列既可以是虚拟的（记录读取的时候火线计算“on the fly”），也可以存储（记录插入或更新的时候计算）。更多信息参考Section 13.1.18.8, “CREATE TABLE and Generated Columns”。

l Mysql客户端。
以前，mysql里如果有执行的语句，“Control+C”打断执行；如果没有，退出mysql。现在如果有执行的语句，“Control+C”打断执行，或者另外会清除任何部分输入，但是不会退出mysql。

l 使用mysqlbinlog修改库名。
现在支持通过在MySQL 5.7.1中添加的--rewrite-db选项使用mysqlbinlog读取基于行格式（“row-based”）写的二进制日志时重命名数据库。

该选项使用格式“--rewrite-db='dboldname->dbnewname'”。通过多次指定该选项，你可以执行多个修改策略。

l 分区表HANDLER。
HANDLER语句现在可以用于用户分区表。这些表可能使用可用分区类型中的任何一个（参考Section 22.2, “Partitioning Types”）。

l Index condition pushdown支持分区表。
在使用InnoDB或者MyISAM存储引擎分区表上的查询可能利用MySQL 5.6引进的ICP优化。更多信息参考Section 8.2.1.5, “Index Condition Pushdown Optimization”。

l WITHOUT VALIDATION支持ALTER TABLE ... EXCHANGE PARTITION。
自MySQL 5.7.5起，ALTER TABLE ... EXCHANGE PARTITION语法包含一个“{WITH|WITHOUT} VALIDATION”子句选项。如果指定了“WITHOUT VALIDATION”，对一个密集的表分区时，ALTER TABLE ... EXCHANGE PARTITION不再进行逐行检验，以允许数据库管理员承担确保记录都处于分区定义范畴的责任。“WITH VALIDATION”是默认行为，不需要显式指定。更多信息参考Section 22.3.3, “Exchanging Partitions and Subpartitions with Tables”。

l Master dump thread改进。
master dump thread被重构以减少连接锁以及提高吞吐量。MySQL 5.7.2以前，dump thread读取事件的时候对二进制日志加锁；MySQL 5.7.2及以后，该锁只有在上一个成功写入事件结束，读取位置的时候才会持有。这就意味着，不但多个dump thread现在可以并发地读取二进制日志文件，而且dump thread现在可以读取客户端正在写入的二进制日志。

l 全球化改进。
MySQL 5.7.4包含一个支持中国国家标准“GB18030”字符集的“gb18030”字符集。关于MySQL字符集支持的更多信息参考Section 10.1, “Character Set Support”。

l 无需STOP SLAVE修改主库。
MySQL 5.7.4以及之后的版本，发出任何CHANGE MASTER TO指令前执行STOP SLAVE的刻意要求被移除。不用再依赖于slave是否关闭，“CHANGE MASTER TO”的行为依赖于slave SQL thread和slave I/O thread的状态；这些线程哪些处于停止状态、哪些处于运行状态，现在左右给定点上是否能够及时执行“CHANGE MASTER TO”语句的抉择。作出该选择的规则列出如下：

Ø 如果SQL thread停止，即便I/O thread正在运行，你可以使用“RELAY_LOG_FILE”、“RELAY_LOG_POS”和“MASTER_DELAY”选项的任意组合执行“CHANGE MASTER TO”。当I/O thread运行的时候再没有其他可用选项了。

Ø 如果I/O thread停止，即便SQL thread正在运行，你可以使用除了“RELAY_LOG_FILE”、“RELAY_LOG_POS”和“MASTER_DELAY”以外，作用于“CHANGE MASTER TO”语句的任何选项（以任何许可的组合）执行它。当I/O thread运行的时候这三个选项不能使用。

Ø 发出“CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1”命令前SQL thread和I/O thread都必须停止运行。

你可以使用SHOW SLAVE STATUS检查从库SQL thread和I/O thread的当前状态。

如果你在使用基于语句的复制和临时表，跟着“STOP SLAVE”语句执行的“CHANGE MASTER TO”语句可能把临时表遗留到从库。作为这种设置改进的一部分，当基于语句的复制正在使用中并且Slave_open_temp_tables的数量依然大于0，当跟着“STOP SLAVE”发出“CHANGE MASTER TO”命令时，现在会抛出一个警告。

更多信息参考Section 13.4.2.1, “CHANGE MASTER TO Syntax”, and Section 16.3.7, “Switching Masters During Failover”。

l 测试套件。
MySQL测试套件现在使用InnoDB作为默认存储引擎。

l Multi-source replication现在是可以的。
MySQL Multi-Source Replication增加了从多个主库向一个从库复制的功能。MySQL Multi-Source Replication拓扑结构可以用于备份多台服务器到一台服务器，合并表格碎片以及把多台服务器上的数据统一到一台服务器上。参考Section 16.1.4, “MySQL Multi-Source Replication”。

作为MySQL Multi-Source Replication的一部分，添加了复制通道。复制通道使得一个从库可以开启多个连接来接收复制，每个通道作为一个主库的一个连接。参考Section 16.2.3, “Replication Channels”。

l Performance Schema组群复制表。
MySQL 5.7添加了一批新表到Performance Schema中，以提供复制组群和通道的信息。这包括以下表格：

replication_applier_configuration

replication_applier_status

replication_applier_status_by_coordinator

replication_applier_status_by_worker

replication_connection_configuration

replication_connection_status

replication_group_members

replication_group_member_stats

除了MySQL 5.7.6添加的“replication_group_members”和“replication_group_member_stats”以外，所有的这些表添加于MySQL 5.7.2。更多信息参考Section 25.11.11, “Performance Schema Replication Tables”。

l 组群复制SQL。
MySQL 5.7.6添加了以下语句来控制组群复制：

START GROUP_REPLICATION

STOP GROUP_REPLICATION

更多信息参考Section 13.4.3, “SQL Statements for Controlling Group Replication”。