Mysql5.7官⽅⽂档翻译
始于 2017年4⽉1⽇-愚⼈节
1.1 MySQL 5.7 新功能
本章节介绍了MySQL 5.7 新版本中新增、废弃、删除的功能。在1.5章节 Section 1.5, “Server and Status Variables and Options Added, Deprecated, or Removed in MySQL 5.7” 中可以获得详细信息。.
MySQL 5.7 新增功能
MySQL 5.7 废弃功能
MySQL 5.7 删除功能
MySQL 5.7 新增功能
以下是 MySQL 5.7新增的功能选项:
server error翻译安全增强. :
该版本要求在mysql.user 中的plugin字段⾮空并且禁⽌accounts 为空值。要查看server 升级的事项请看 2.11.1.1 章节Section 2.11.1.1,“Changes Affecting Upgrades to MySQL 5.7”. mysql 建议DBA 使⽤mysql_native_password 代替mysql_old_password.因为
mysql_old_password 已经删除不再⽀持。对于账户升级请查看7.5.1.3章节Section 7.5.1.3, “Migrating Away from Pre-4.1 Password Hashing and the mysql_old_password Plugin”.
MySQL 现在允许数据库管理员利⽤策略创建⼀个⾃动过期的账户。任何连⼊数据库server的过期账户必须要修改密码。在章节7.3.6 Section 7.3.6, “Password Expiration Policy”. 有详细介绍。
管理员能够锁定或者解锁，以便更你好的控制谁能登⼊，查看章节7.3.10 Section 7.3.10, “User Account Locking”. 有详细介绍。
为了更简单的⽀持安全连接，MySQL server 能够在启动的时候能够使⽤Openssl⾃动⽣成丢失的RSA 认证⽂件.在7.4.6.1 章节 Section
7.4.6.1, “Creating SSL and RSA Certificates and Keys using MySQL”. 有详细介绍。
所有server 不管是Openssl 或者yaSSL ，既是没有显式的配置SSL，当服务器启动的时候发现在数据⽬录有SSL ⽂件会舱室⾃动启⽤SSL 。在 7.4.4 章节 Section 7.4.4, “Configuring MySQL to Use Secure C
onnections”. 有详细介绍。
另外MySQL 还配置了⼀个包含mysql_ssl_rsa_setup 的功能包，这样使得你能够⼿动的创建SSL和RSA 密钥认证⽂件在章节5.4.5 Section 5.4.5, “mysql_ssl_rsa_setup — Create SSL/RSA Files”.有详细介绍。
MySQL 部署初始化使⽤ mysqld --initialize 做安全默认项. 下⾯列出的项是mysql 在部署的时候作为默认项⽬:
Mysql 初始化的时候只创建⼀个root 账户'root'@'localhost', 并为这个账户⾃动⽣成⼀个随机密码, 并将密码设置为过期状态. MySQL 管理员必须使⽤这个密码登⼊并设置要给新的密码，（服务器将随机密码写⼊error ⽇志⽂件中）
初始化的时候不会创建匿名账户。
初始化的时候不会创建test 库。
查看章节2.10.1.1 Section 2.10.1.1, “Initializing the Data Directory Manually Using mysqld”.有更多详细信息。
SQL mode 做了变更. STRICT_TRANS_TABLES 现在变更为默认.
ONLY_FULL_GROUP_BY SQL mode 更为精确, 以前版本拒绝的查询已经不在拒绝. 因此, 该模式默认是开启的, 现在只拒绝那些在组中不能保证是唯⼀的不确定的查询. ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, 和 NO_ZERO_IN_DATE SQL modes 现在已经废弃，默认启⽤。在以后的版本中计划中打算将他们加⼊ strict SQL mode 并且将他们显⽰的删除. 在 SQL Mode Changes in MySQL 5.7 该章节中有详细介绍。
可更改的系统默认的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, and NO_ENGINE_SUBSTITUTION.
Online ALTER TABLE 在线修改表. alter table 命令现在能够通过rename index 来重命名索引的名称ALTER TABLE now supports a RENAME INDEX clause that renames an index. 该项更改是源修改模式（in-place）不需要表拷贝操作，对所有引擎有效。该项更改是在内部修改（in-place）不需要复制表操作，对所有引擎有效。在14.1.8 章节 Section 14.1.8, “ALTER TABLE Syntax”.有详细介绍。
ngram and MeCab full-text 分析插件. MySQL 提供了⼀个内置的全⽂ ngram 分析插件⽀持中⽂、⽇⽂、韩⽂和⼀个可安装的 MeCab 全⽂分析⽇语插件。在13.9.8章节Section 13.9.8, “ngram Full-Text Parser”, 和13.9.9章节Section 13.9.9, “MeCab Full-Text Parser Plugin”.由详细描述。
InnoDB 增强. :
VARCHAR 字段的⼤⼩能够通过 ALTER TABLE，命令，以in-place 的⽅式修改，例如 :
ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);
This is true as long as the number of length bytes required by a VARCHAR column remains the same.只要修改字段后字段varchar所占字节数和原先的相同就能实现，例如对于 VARCHAR 值在 0到 255，只需要⼀个bytes. 对于 VARCHAR 的值是 256 bytes 或者⼤于256 需要两个字节.这样的话，通过 in-place ALTER TABLE 只⽀持0到255 之间的修改，或者说256 以及⼤于256之间修改.in-place alter table 不⽀持⼩于256的varchar值变更为⼤于256的值。因为在这种情况下存储的字节会从1个字节变为两个字节。只能通algorithm=copy的⽅式修改，例如将varchar (255)的值修改到256 in-place alter would 会返回⼀个错误
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.
使⽤IN-PLACE alter table 减少varchar 的⼤⼩是不⽀持的。减少字段⼤⼩需要复制表操作(ALGORITHM=COPY).
对于INNODB 引擎临时表的DLL CREATE TABLE, DROP TABLE, TRUNCATE TABLE, and ALTER TABLE 做了增强.
InnoDB 临时表的元信息现在不存放在 InnoDB 系统表中. 替代的是⼀张新表 INNODB_TEMP_TABLE_INFO, 可供查询到的是⽤户在使⽤的临时表snapshot . 这张表记录了所有⽤户和系统⾃⼰创建的在innodb 实例中的临时表信息。当第⼀次使⽤.当当select 语句第⼀次运⾏的时候这张表就创建了
InnoDB 现在⽀持空间数据类型. 在这之前的版本, InnoDB 只能将空间数据类型做为⼆进制的 BLOB 来存储. BLOB 是基本的存储类型但是空间数据类型类型现在已经作为⼀种新的 InnoDB 引擎内部数据类型, DATA_GEOMETRY.
对于所有没压缩的INNODB 引擎临时表现在提供各⾃的表空间. 每当server startup 新的表空间都会重新创建，并且默认在DATADIR 指定⽬录. ⼀个新的参数 innodb_temp_data_file_path, 允许⽤户⾃定义临时表的存放地址.
innochecksum 功能现在做了增强并提供了⼏个新的参数扩展其能⼒。章节 5.6.1 Section 5.6.1, “innochecksum — Offline InnoDB File Checksum Utility”.有更详细信息。
对于普通的或者压缩的临时表以及相关的对象现在⽤⼀种新的non-redo undo log 存放在临时表空间中. 章节15.4.12.1 Section 15.4.12.1,“InnoDB Temporary Table Undo Logs” 有详细信息.
InnoDB buffer pool 转储和加载做了加强.使⽤ innodb_buffer_pool_dump_pct，参数能够让你指定百分⽐的转储buffer_pool 中的数据，当操作的时候有其他的活动的IO操作在innodb 的后台。 INNODB 尝试使⽤ innodb_io_capacity 参数来限制每秒从buffer pool 中加载的数据量. InnoDB ⽀持全⽂索引. 查看章节 Full-Text Parser Plugins 和 Section 27.2.4.4, “Writing Full-Text Parser Plugins”.
InnoDB 在清空buffer pool 中的脏数据的使⽤可以使⽤innodb_page_cleaner 指定多个清除线程这个参数值默认是1.
对于下⾯列出的选项，MySQL 能够定期和分步使⽤online DDL (ALGORITHM=INPLACE) :
OPTIMIZE TABLE
ALTER TABLE ... FORCE
ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB table)
Online DDL 能够减少时间并且⽀持并发，这样能有有效减少停机时间章节15.13.1 Section 15.13.1, “Overview of Online DDL” 有详细介绍. linux 的 Fusion-io Non-Volatile Memory (NVM) ⽂件系统提供了原⼦的（atomic）写扩展能⼒，使得 InnoDB doublewrite buffer 冗余. 对于在fusion-io⽀持原⼦写的设备上系统表空间 (ibdata files) 的InnoDB doublewrite buffer ⾃动禁⽤ .
InnoDB 对于分区表和单个的分区⽀持 t Transportable Tablespace . 这个增强使得在不同的server之间备份迁移分区表变得简化了章节15.7.6 Section 15.7.6, “Copying File-Per-Table Tablespaces to Another Server” 有详细介绍.
参数 innodb_buffer_pool_size 现在可动态修改，不需要停机修改. 这个更改操作通过操作块（chunks）复制页到新的内存⾥⾯来实现。. Chunk 的⼤⼩由参数 innodb_buffer_pool_chunk_size 来指定.你可以通过监控视图 Innodb_buffer_pool_resize_status 来观察进度. 查看章节Configuring InnoDB Buffer Pool Size Online 有更多消息.
Multi-threaded page cleaner support (innodb_page_cleaners) is 会延长 shutdown 和 recovery phases时间.
InnoDB ⽀持空间数据索引 including use of ALTER TABLE ... ALGORITHM=INPLACE for online operations (ADD SPATIAL INDEX). InnoDB 在创建或者创建indexes 的时候会执⾏⼀个⼤块的加载. 这
种创建索引的⽅式通常称为 “sorted index build”. 这项加强提升了创建索引的效率，对于全⽂索引也有效.⼀个闲的全局变量innodb_fill_factor, 定义了在sorted index build 期间每个页存放数据的⽐率, 保留的空间⽤作未来索引的增长章节 15.8.2 Section 15.8.12, “Sorted Index Builds” 有详细介绍.
⼀个新的⽇志记录类型 (MLOG_FILE_NAME) ⽤来记录表空间⾃上次checkpoint 之后的更改.这项增强使得在恢复时刻计算redolog 量表少变快。章节 15.18.2 Section 15.18.2, “Tablespace Discovery During Crash Recovery” 有详细介绍.
这项增强变更了redo log 的格式，需要关机.
你可以清空保留在undo tablespace 的 undo logs . 通过参数 innodb_undo_log_truncate 控制. 章节15.7.8 Section 15.7.8, “Truncating Undo Logs That Reside in Undo Tablespaces” 有详细介绍.
InnoDB ⽀持原⽣ partitioning. 在早前, InnoDB 需要依靠 ha_partition 保持，为每⼀个分区创建⼀个hander. 对于原⽣分区，⼀张分区 InnoDB
表使⽤⼀个单独的 partition-aware handler 对象. 这项增强可以减少分区表使⽤内存的量。
对于MySQL 5.7.9 mysql_upgrade 查并尝试升级先前的使⽤ ha_partition handler. 并且在MySQL 5.7.9和以后的版本中, 你可以直接通过client 发出命令来升级ALTER TABLE ... UPGRADE PARTITIONI
NG.
InnoDB ⽀持创建通⽤的表空间语法如下 CREATE TABLESPACE.
CREATE TABLESPACE tablespace_name
ADD DATAFILE 'file_name.ibd'
[FILE_BLOCK_SIZE = n]
通⽤表空间能够创建存放在datadir 之外的地⽅，能够存放多表并且⽀持表的all row 格式。
往通⽤表空间中新增表使⽤CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name 或者 ALTER TABLE tbl_name TABLESPACE [=] tablespace_name 的语法.
章节15.7.9 Section 15.7.9, “InnoDB General Tablespaces” 有更多详细信息。
DYNAMIC 替代 COMPACT 作为隐式的INNODB 表的row format . 利⽤参数 innodb_default_row_format, 来指定默认的InnoDB row format.章节15.11.2 Section 15.11.2, “Specifying the Row Format for a Table” 有详细信息.
MySQL 5.7.11版本中, InnoDB ⽀持为每⼀个file-per-table 的表空间进⾏data-at-rest 加密 . 当创建或者修改innodb表的时候指定ENCRYPTION 参数就会开启加密功能. 这项功能，需要依赖 InnoDB 表空间加密, 依赖于 keyring 插件. 章节5.7.4 Section 7.5.4, “The MySQL Keyring”, 和15.7.10 Section 15.7.10, “InnoDB Tablespace Encryption” 有更多纤细信息.
JSON support. 从版本5.7.8开始⽀持原⽣的 JSON 格式. josn 数据不再以字符串的形式存储，⽽是以内部⼆进制的格式允许快速的读取⽂档元素。以json 列存放的json⽂档在更新或者插⼊的时候会⾃动校验。如果是不符合的格式会抛出异常。json 在创建上和普通列上并⽆差别并且能够进⾏ =, <, <=, >, >=, <>, !=，和 <=>; 等⼤多数中形式运算章节 Comparison and Ordering of JSON Values 有更多介绍。
MySQL 5.7.8 还引⼊了众多的函数来⽀持json数据的操作:
创建 JSON 数据: JSON_ARRAY(), JSON_MERGE(), 、 JSON_OBJECT(). 更多查看章节 Section 13.16.2, “Functions That Create JSON Values”.
搜索 JSON 数据: JSON_CONTAINS(), JSON_CONTAINS_PATH(), JSON_EXTRACT(), JSON_KEYS(), and JSON_SEARCH(). 更多查看章节 Section 13.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(), and JSON_UNQUOTE(). 更多查看章节 Section 13.16.4, “Functions That Modify JSON Values”.
查看 JSON 数据信息: JSON_DEPTH(), JSON_LENGTH(), JSON_TYPE(), and JSON_VALID(). 更多查看章节 Section 13.16.5, “Functions That Return JSON Value Attributes”.
在 5.7.9以及之后的版本⾥⾯, 你可以使⽤ column->path 作为快速的 JSON_EXTRACT(column, path). 通过这种⽅式将其作为⼀种列类似于别名的⽅式在sql中使⽤, 也可以在 WHERE, ORDER BY, and GROUP BY 的条件中使⽤.这些包括SELECT, UPDATE, DELETE, CREATE TABLE, 和其他的 SQL 语句. 左边的必须是json 列，右边的是引⽤josn path 的表达式该表达式是json⽂档返回的值
查看章节13.16.3 Section 13.16.3, “Functions That Search JSON Values”, 有跟多有关于 -> 和 JSON_EXTRACT() .的信息，章节Searching and Modifying JSON Values.有更多有关MySQL 5.7对json⽀持的信息。 json索引请查看这⼀章节 Indexing a Generated Column to Provide a JSON Column Index.
System and status variables. 系统和状态变量系统和状态变量信息现在在performance schmema的表中能够展⽰了。表INFORMATION_SCHEMA 的表现在包含那些变量.这也涉及了 SHOW VARIABLES 和 SHOW STATUS 语句. 变量 show_compatibility_56系统变量控制着查询状态的输出.章节6.1.5 Section 6.1.5, “Server System Variables”. 有更多详细信息。
Note
变量 show_compatibility_56 默认 OFF. 程序在使⽤环境是5.6版本的时候需要将改值设置为ON 。章节24.18 Section 24.18, “Migrating to Performance Schema System and Status Variable Tables” 有更多详细信息。
sys schema. 系统schema MySQL 分⽀现在包含了 sys schema, 这个schema提供给DBA和开发⼈员获取数据库的性能信息。 sys schema 包含的对象能够⽤来分析诊断数据库。章节25 Chapter 25, MySQL sys Schema. 有更多详细信息
Condition handling 条件处理. MySQL 现在⽀持 stacked diagnostics areas. 章节14.6.7.3 Section 14.6.7.3, “GET DIAGNOSTICS Syntax”, 和Section 14.6.7.7, “The MySQL Diagnostics Area”.有更多详细信息。
Optimizer.优化器优化器加强了，并且也新增了以下内容:
EXPLAIN 能够获得其它连你的执⾏计划：
EXPLAIN [options] FOR CONNECTION connection_id;
章节9.8.4 Section 9.8.4, “Obtaining Execution Plan Information for a Named Connection”. 有更多信息。
现在能够为单个sql 添加hinst 作为优化⽅式，能够出⾊的控制语句的执⾏计划，通过设置 optimizer_switch 来实现. 在获取执⾏计划的时候
也可以使⽤，章节9.9.3Section 9.9.3, “Optimizer Hints”. 有更多详细信息。
Triggers. 触发器 ，早前⼀张表最多只能有⼀个同类触发器 (INSERT, UPDATE, DELETE) action time (BEFORE, AFTER). 这个限制已经被突破了并且允许多触发器存在章节22.3 Section 22.3, “Using Triggers”.有更多详细信息。
Logging ⽇志. :
以前的版本中, 在unix和类unix的系统中, MySQL 通过mysqld_safe 将server error ⽇志发送到syslog . 现在server ⽀持原⽣的 syslog, 也扩展到了windows系统中.章节6.4.2 Section 6.4.2, “The Error Log”. 有更多详细信息。
mysql 客户端现在有⼀个--syslog 选项能够和系统交互写⼊ syslog. 类似于 ("IDENTIFIED:PASSWORD"), 不会写⼊syslog 其他的也可以通过参数--histignore 控制. 5.5.1.3 章节 Section 5.5.1.3, “mysql Logging”.有更多详细信息。
Generated Columns ⽣成列. MySQL在 CREATE TABLE 和ALTER TABLE 的时候⽀持⽣成列。⽣成列的值可以通表达式产⽣. ⽣成列可以是虚拟列也可以是stred章节14.1.18.7 Section 14.1.18.7, “CREATE TABLE and Generated Columns”.有更多详细信息。
mysql client mysql 客户端. 早前, Control+C 能够终⽌当前语句或者退出客户端. Now Control+C 会终⽌当前语句或者其他输⼊但是不会退出客户端程序。
Database name rewriting with mysqlbinlog . 从5.7.1 开始对于以row格式的binlog，使⽤⼯具mysqlbinlog时，可以通过参数–rewrite-db修改dbname，使⽤格式：--rewrite-db='dboldname->dbnewname'
参数的格式为 --rewrite-db='dboldname->dbnewname'. 你可以书写多个规则来多次指定
HANDLER with partitioned tables分区表和handler. ⽤户的分区表也能够使⽤HANDLER 语句了.更多查看章节21.2 (see Section 21.2,“Partitioning Types”).
Index condition pushdown support for partitioned tables 分区表⽀持索引下推ICP. 使⽤INNODB 和MyISAM 引擎的分区表查询可以使⽤5.6已经引进的 index condition pushdown (ICP)优化⽅式。章节9.2.1.6 Section 9.2.1.6, “Index Condition Pushdown Optimization”，有更多详细介绍.
WITHOUT VALIDATION support for ALTER TABLE ... EXCHANGE PARTITION 分区交换不需校验. MySQL5.7.5版本开始, ALTER TABLE ... EXCHANGE PARTITION 命令包含了⼀个 {WITH|WITHOUT} VALIDATION 选项. 当指定WITHOUT VALIDATION 时, ALTER TABLE ... EXCHANGE PARTITION 做分区交换是允许数据库管理员去假设分区的边界。如果超出边界出错，没超出则正常运⾏。 WITH VALIDATION.是默认值，不需要显式设置。章节21.3.3 Section 21.3.3, “Exchanging Partitions and Subpartitions with Tables”. 有更多详细介绍。
Master dump thread improvements master 转储线程增强. master 转储现场做了重构减少了锁并且提⾼了maste的吞吐率。早前的5.7.2版本中转储现场再读取⼆进制⽇志时会获取⼀个锁。在之后的版本中，获得锁只是在读取到最后⼀个成功写⼊的事件时。这意味着多线程的转储已经⽀持还意味着，转储线程在客户端写⼆进制时也能够读取。.
Globalization improvements 全球化⽀持增强. MySQL 5.7.4 新增了字符集 gb18030 . 章节11.1 Section 11.1, “Character Set Support”.有更多介绍。
Changing the replication master without STOP SLAVE 复制架构修改master 不需要停⽌slave. MySQL 5.7.4 以及之后的版本, 在 CHANGE MASTER TO 之前不在需要执⾏stop slave 命令 . 现在决定slave 是否需要停⽌的是 slave sql thread 和 slave I/O thread . I:
如果 SQL thread停⽌了, 你可以执⾏ CHANGE MASTER TO using any combination of RELAY_LOG_FILE, RELAY_LOG_POS, and MASTER_DELAY options，即使 slave I/O thread还在运⾏.
如果 I/O thread 停⽌了, 你可以执⾏ CHANGE MASTER TO 并使⽤除了 RELAY_LOG_FILE, RELAY_LOG_POS, 和MASTER_DELAY, 之外的任何选项。即使 SQL thread 还在运⾏. 这三个选项当I/O thread 在运⾏的时候不要使⽤
SQL thread and the I/O thread 都必须停⽌当参数 CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1.时
你可以使⽤SHOW SLAVE STATUS.查看sql thread 和I/O thread 的状态。
如果你使⽤statement-based 的复制和临时表，在执⾏stop slave 后执⾏ CHANGE MASTER TO 会遗留临时表在slave。做为这部分的增强现在执⾏stop slave 时会抛出⼀个警告warning。当这个复制使⽤ Slave_open_temp_tables 并值为0 时。
章节14.4.2.1 Section 14.4.2.1, “CHANGE MASTER TO Syntax”, 和章节18.3.7 Section 18.3.7, “Switching Masters During Failover”. 有详细信息。
Test suite. MySQL test suite 使⽤ InnoDB 作为默认存储引擎。
Multi-source replication is now possible.现在⽀持多主复制了 MySQL 多源复制⽀持多个master 往⼀个slave 复制. MySQL 多源复制的拓扑能够将多个server 备份到单个server 上。 to back up multiple servers to a single server, 从多server 合并分⽚和收集数据到单个server 章节18.1.4Section 18.1.4, “MySQL Multi-Source Replication”. 有详细介绍。
作为多源复制的⼀部分, 复制管道做了增加 ,Replication channels 运⾏slave 同时开启多个连接到多个连接源章节18.2.3 Section 18.2.3,“Replication Channels”. 有详细介绍。
Group Replication Performance Schema tables Group Replication 性能视图表. MySQL 5.7 在Performance Schema 中为 replication groups
和channels 新增了⼤量的性能视图表：
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.2 开始引⼊上述表, 另外需要注意的是 replication_group_members 和 replication_group_member_stats, 两张表是 MySQL 5.7.6.t 提供的详细信息查看 Section 24.10.11, “Performance Schema Replication Tables”.
Group Replication SQL. Group Replication SQL. 在 MySQL 5.7.6 中引⼊了下列参数对组复制进⾏控制:
START GROUP_REPLICATION
STOP GROUP_REPLICATION
详细信息查看 Section 14.4.3, “SQL Statements for Controlling Group Replication”.
MySQL 5.7 中废弃的功能
The following features are deprecated in MySQL 5.7 and may be or will be removed in a future series 下列的功能在Mysql 5.7 中是废弃的功能并且可能在未来的版本中删除. Where alternatives are shown, applications should be updated to use them.
ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, 和 NO_ZERO_IN_DATE SQL modes 已被废弃并默认启⽤. 未来的计划是将他们集成到 strict SQL mode 并完全除去.
为了防⽌语句不出现错误模式 ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE 当前依然是建议的, 但是在新的版本中将会被删除.
⽤户管理发⽣变化:
不能再使⽤grant 创建⽤户替代的CREATE USER. 这就使得关联的NO_AUTO_CREATE_USER SQL mode ⽆效所以被废弃.
Using GRANT to modify account properties other than privilege assignments. This includes authenticat
ion, SSL, and resource-limit properties. Instead, establish such properties at account-creation time with CREATE USER or modify them afterward with ALTER USER.使⽤GRANT 修改⽤户账户属性⽽不是通过权限分配，包括认证，SSL，和资源属性。代替在创建⽤户和alter user的时候处理属性。
IDENTIFIED BY PASSWORD 'hash_string' syntax for CREATE USER and GRANT. Instead, use IDENTIFIED WITH auth_plugin AS
'hash_string' for CREATE USER and ALTER USER, where the 'hash_string' value is in a format compatible with the named plugin. CREATE USER and GRANT 使⽤的IDENTIFIED BY PASSWORD 'hash_string'语法被 CREATE USER and ALTER USER中的语法IDENTIFIED WITH auth_plugin AS 'hash_string' 代替
The PASSWORD() function is deprecated and should be avoided in any context. Thus, SET PASSWORD ... = PASSWORD('auth_string') syntax is also deprecated. SET PASSWORD ... = 'auth_string' syntax is not deprecated; nevertheless, ALTER USER is now the preferred statement for assigning passwords.
PASSWORD()函数被废弃，同样= password(‘string_word’) 同样被废弃，然⽽set password='string_word' 却被有被废弃。alter user 现在被⽤来设置⽤户的密码。
The old_passwords system variable. Account authentication plugins can no longer be left unspecified in the mysql.user table, so any statement that assigns a password from a cleartext string can unambiguously determine the hashing method to use on the string before storing it in the mysql.user table. This renders old_passwords superflous.
系统变量old_password , 账户认证插件在mysql 表中现在必须指定
Relying on implicit GROUP BY sorting in MySQL 5.7 is deprecated. To achieve a specific sort order of grouped results, it is preferable to use an explicit ORDER BY clause. GROUP BY sorting is a MySQL extension that may change in a future release; for example, to make it possible for the optimizer to order groupings in whatever manner it deems most efficient and to avoid the sorting overhead.
隐式的group by 排序在mysql 5.7中已经被废弃，为了指定排序顺序必须显⽰指定ORDER BY 的。group by 排序在未来的mysql 版本中会提供。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。