Data dictionary.数据字典。  MySQL now incorporates a transactional data dictionary that stores information about database objects. MySQL现在合并了一个事务数据字典，它存储有关数据库对象的信息。In previous MySQL releases, dictionary data was stored in metadata files and nontransactional tables. 在以前的MySQL版本中，字典数据存储在元数据文件和非事务表中。For more information, see Chapter 14, MySQL Data Dictionary.有关更多信息，请参阅第14章，MySQL数据字典。

Atomic data definition statements (Atomic DDL).原子数据定义语句（Atomic DDL）。  An atomic DDL statement combines the data dictionary updates, storage engine operations, and binary log writes associated with a DDL operation into a single, atomic transaction. 原子DDL语句将数据字典更新、存储引擎操作和与DDL操作相关联的二进制日志写入合并到单个原子事务中。For more information, see Section 13.1.1, “Atomic Data Definition Statement Support”.有关更多信息，请参阅第13.1.1节，“原子数据定义语句支持”。

Upgrade procedure.升级过程。  Previously, after installation of a new version of MySQL, the MySQL server automatically upgrades the data dictionary tables at the next startup, after which the DBA is expected to invoke mysql_upgrade manually to upgrade the system tables in the mysql schema, as well as objects in other schemas such as the sys schema and user schemas.此前，安装了新版MySQL后，MySQL服务器会在下次启动时自动升级数据字典表，之后DBA会手动调用mysql_upgrade来升级mysql架构中的系统表，以及sys架构和user架构等其他架构中的对象。

As of MySQL 8.0.16, the server performs the tasks previously handled by mysql_upgrade. 从MySQL 8.0.16开始，服务器执行mysql_upgrade之前处理的任务。After installation of a new MySQL version, the server now automatically performs all necessary upgrade tasks at the next startup and is not dependent on the DBA invoking mysql_upgrade. 安装新的MySQL版本后，服务器现在会在下一次启动时自动执行所有必要的升级任务，并且不依赖于调用mysql_upgrade的DBA。In addition, the server updates the contents of the help tables (something mysql_upgrade did not do). 此外，服务器更新帮助表的内容（mysql_upgrade没有做到这一点）。A new --upgrade server option provides control over how the server performs automatic data dictionary and server upgrade operations. 一个新的--upgrade server选项提供了对服务器如何执行自动数据字典和服务器升级操作的控制。For more information, see Section 2.11.3, “What the MySQL Upgrade Process Upgrades”.有关更多信息，请参阅第2.11.3节，“MySQL升级过程升级的内容”。

Security and account management.安全和帐户管理。  These enhancements were added to improve security and enable greater DBA flexibility in account management:添加这些增强功能是为了提高安全性并增强DBA在帐户管理方面的灵活性：

Resource management.资源管理。  MySQL now supports creation and management of resource groups, and permits assigning threads running within the server to particular groups so that threads execute according to the resources available to the group. MySQL现在支持创建和管理资源组，并允许将服务器中运行的线程分配给特定的组，以便线程根据组可用的资源执行。Group attributes enable control over its resources, to enable or restrict resource consumption by threads in the group. 组属性启用对其资源的控制，以启用或限制组中线程的资源消耗。DBAs can modify these attributes as appropriate for different workloads. DBA可以根据不同的工作负载修改这些属性。Currently, CPU time is a manageable resource, represented by the concept of “virtual CPU” as a term that includes CPU cores, hyperthreads, hardware threads, and so forth. 目前，CPU时间是一种可管理的资源，由“虚拟CPU”的概念表示，该术语包括CPU核心、超线程、硬件线程等。The server determines at startup how many virtual CPUs are available, and database administrators with appropriate privileges can associate these CPUs with resource groups and assign threads to groups. 服务器在启动时确定有多少虚拟CPU可用，具有适当权限的数据库管理员可以将这些CPU与资源组关联，并为组分配线程。For more information, see Section 5.1.16, “Resource Groups”.有关更多信息，请参阅第5.1.16节，“资源组”。

Table encryption management.表加密管理。  Table encryption can now be managed globally by defining and enforcing encryption defaults. 现在可以通过定义和强制加密默认值来全局管理表加密。The default_table_encryption variable defines an encryption default for newly created schemas and general tablespace. default_table_encryption变量为新创建的架构和常规表空间定义加密默认值。The encryption default for a schema can also be defined using the DEFAULT ENCRYPTION clause when creating a schema. 在创建架构时，还可以使用DEFAULT ENCRYPTION子句定义架构的加密默认值。By default, a table inherits the encryption of the schema or general tablespace it is created in. 默认情况下，表将继承创建它的架构或常规表空间的加密。Encryption defaults are enforced by enabling the table_encryption_privilege_check variable. 通过启用table_encryption_privilege_check变量强制执行加密默认值。The privilege check occurs when creating or altering a schema or general tablespace with an encryption setting that differs from the default_table_encryption setting, or when creating or altering a table with an encryption setting that differs from the default schema encryption. 使用不同于default_table_encryption设置的加密设置创建或更改架构或常规表空间时，或者使用不同于默认架构加密设置的加密设置创建或更改表时，会发生权限检查。The TABLE_ENCRYPTION_ADMIN privilege permits overriding default encryption settings when table_encryption_privilege_check is enabled. 启用table_encryption_privilege_check时，TABLE_ENCRYPTION_ADMIN权限允许覆盖默认加密设置。For more information, see Defining an Encryption Default for Schemas and General Tablespaces.有关更多信息，请参阅为架构和常规表空间定义加密默认值。

InnoDB enhancements.InnoDB增强功能。  These InnoDB enhancements were added:添加了以下InnoDB增强功能：

Character set support.字符集支持。  The default character set has changed from latin1 to utf8mb4. 默认字符集已从latin1更改为utf8mb4。The utf8mb4 character set has several new collations, including utf8mb4_ja_0900_as_cs, the first Japanese language-specific collation available for Unicode in MySQL. utf8mb4字符集有几个新的排序规则，包括utf8mb4_ja_0900_as_cs，这是MySQL中第一个针对Unicode的日语特定排序规则。For more information, see Section 10.10.1, “Unicode Character Sets”.有关详细信息，请参阅第10.10.1节，“Unicode字符集”。

JSON enhancements.JSON增强。  The following enhancements or additions were made to MySQL's JSON functionality:对MySQL的JSON功能进行了以下增强或添加：

Data type support.数据类型支持。  MySQL now supports use of expressions as default values in data type specifications. MySQL现在支持在数据类型规范中使用表达式作为默认值。This includes the use of expressions as default values for the BLOB, TEXT, GEOMETRY, and JSON data types, which previously could not be assigned default values at all. 这包括使用表达式作为BLOB、TEXT、GEOMETRY和JSON数据类型的默认值，这些数据类型以前根本不能被分配默认值。For details, see Section 11.6, “Data Type Default Values”.有关详细信息，请参阅第11.6节，“数据类型默认值”。

Optimizer.优化器。  These optimizer enhancements were added:添加了以下优化程序增强功能：

Common table expressions.常用表表达式。  MySQL now supports common table expressions, both nonrecursive and recursive. MySQL现在支持非递归和递归的通用表表达式。Common table expressions enable use of named temporary result sets, implemented by permitting a WITH clause preceding SELECT statements and certain other statements. 公共表表达式允许使用命名的临时结果集，通过允许在SELECT语句和某些其他语句之前使用WITH子句来实现。For more information, see Section 13.2.15, “WITH (Common Table Expressions)”.有关更多信息，请参阅第13.2.15节，“WITH（公共表表达式）”。

As of MySQL 8.0.19, the recursive SELECT part of a recursive common table expression (CTE) supports a LIMIT clause. 从MySQL8.0.19开始，递归公共表表达式（CTE）的递归SELECT部分支持LIMIT子句。LIMIT with OFFSET is also supported. 还支持带OFFSET的LIMIT。See Recursive Common Table Expressions, for more information.有关详细信息，请参阅递归公共表表达式。

Window functions.窗口函数。  MySQL now supports window functions that, for each row from a query, perform a calculation using rows related to that row. MySQL现在支持窗口函数，对于查询中的每一行，使用与该行相关的行执行计算。These include functions such as RANK(), LAG(), and NTILE(). 这些函数包括RANK()、LAG()和NTILE()等函数。In addition, several existing aggregate functions now can be used as window functions (for example, SUM() and AVG()). 此外，一些现有的聚合函数现在可以用作窗口函数（例如SUM()和AVG()）。For more information, see Section 12.21, “Window Functions”.有关更多信息，请参阅第12.21节，“窗口函数”。

Lateral derived tables.横向派生表。  A derived table now may be preceded by the LATERAL keyword to specify that it is permitted to refer to (depend on) columns of preceding tables in the same FROM clause. 现在，派生表前面可以加上LATERAL关键字，以指定允许它在同一FROM子句中引用（依赖）前面表的列。Lateral derived tables make possible certain SQL operations that cannot be done with nonlateral derived tables or that require less-efficient workarounds. 横向派生表使某些SQL操作成为可能，这些操作无法用非横向派生表完成，或者需要效率较低的变通方法。See Section 13.2.11.9, “Lateral Derived Tables”.请参阅第13.2.11.9节，“横向派生表”。

Aliases in single-table DELETE statements.单表DELETE语句中的别名。  In MySQL 8.0.16 and later, single-table DELETE statements support the use of table aliases.在MySQL 8.0.16及更高版本中，单表DELETE语句支持使用表别名。

Regular expression support.正则表达式支持。  Previously, MySQL used the Henry Spencer regular expression library to support regular expression operators (REGEXP, RLIKE). 以前，MySQL使用Henry Spencer正则表达式库来支持正则表达式操作符（REGEXP，RLIKE）。Regular expression support has been reimplemented using International Components for Unicode (ICU), which provides full Unicode support and is multibyte safe. 正则表达式支持已经使用国际Unicode组件（ICU）重新实现，它提供了完整的Unicode支持，并且是多字节安全的。The REGEXP_LIKE() function performs regular expression matching in the manner of the REGEXP and RLIKE operators, which now are synonyms for that function. REGEXP_LIKE()函数以REGEXP运算符和RLIKE运算符的方式执行正则表达式匹配，现在它们是该函数的同义词。In addition, the REGEXP_INSTR(), REGEXP_REPLACE(), and REGEXP_SUBSTR() functions are available to find match positions and perform substring substitution and extraction, respectively. 此外，REGEXP_INSTR()、REGEXP_REPLACE()和REGEXP_SUBSTR()函数分别用于查找匹配位置和执行子字符串替换和提取。The regexp_stack_limit and regexp_time_limit system variables provide control over resource consumption by the match engine. regexp_stack_limit和regexp_time_limit系统变量提供对匹配引擎的资源消耗的控制。For more information, see Section 12.8.2, “Regular Expressions”. 有关更多信息，请参阅第12.8.2节，“正则表达式”。For information about ways in which applications that use regular expressions may be affected by the implementation change, see Regular Expression Compatibility Considerations.有关使用正则表达式的应用程序受实现更改影响的方式的信息，请参阅正则表达式兼容性注意事项。

Internal temporary tables.内部临时表。  The TempTable storage engine replaces the MEMORY storage engine as the default engine for in-memory internal temporary tables. TempTable存储引擎取代MEMORY存储引擎作为内存内部临时表的默认引擎。The TempTable storage engine provides efficient storage for VARCHAR and VARBINARY columns. TempTable存储引擎为VARCHAR和VARBINARY列提供了高效的存储。The internal_tmp_mem_storage_engine session variable defines the storage engine for in-memory internal temporary tables. internal_tmp_mem_storage_engine会话变量定义内存内部临时表的存储引擎。Permitted values are TempTable (the default) and MEMORY. 允许的值是TempTable（默认值）和MEMORY。The temptable_max_ram variable defines the maximum amount of memory that the TempTable storage engine can use before data is stored to disk.testable_max_ram变量定义了在数据存储到磁盘之前，TempTable存储引擎可以使用的最大内存量。

Logging.日志。  Error logging was rewritten to use the MySQL component architecture. 错误日志记录被重写为使用MySQL组件体系结构。Traditional error logging is implemented using built-in components, and logging using the system log is implemented as a loadable component. 传统的错误日志记录是使用内置组件实现的，而使用系统日志记录是作为可加载组件实现的。In addition, a loadable JSON log writer is available. 此外，还提供了一个可加载的JSON日志编写器。To control which log components to enable, use the log_error_services system variable. 要控制要启用哪些日志组件，请使用log_error_services系统变量。For more information, see Section 5.4.2, “The Error Log”.有关更多信息，请参阅第5.4.2节，“错误日志”。

Backup lock.备用锁。  A new type of backup lock permits DML during an online backup while preventing operations that could result in an inconsistent snapshot. 一种新类型的备份锁允许在联机备份期间使用DML，同时防止可能导致快照不一致的操作。The new backup lock is supported by LOCK INSTANCE FOR BACKUP and UNLOCK INSTANCE syntax. LOCK INSTANCE FOR BACKUP语法和UNLOCK INSTANCE语法支持新的备份锁。The BACKUP_ADMIN privilege is required to use these statements.使用这些语句需要BACKUP_ADMIN权限。

Replication.复制。  The following enhancements have been made to MySQL Replication:对MySQL复制进行了以下增强：

Connection management.连接管理。  MySQL Server now permits a TCP/IP port to be configured specifically for administrative connections. MySQL服务器现在允许专门为管理连接配置TCP/IP端口。This provides an alternative to the single administrative connection that is permitted on the network interfaces used for ordinary connections even when max_connections connections are already established. 这提供了一种替代单一管理连接的方法，该方法允许在用于普通连接的网络接口上使用，即使已经建立了max_connections连接。See Section 5.1.12.1, “Connection Interfaces”.请参阅第5.1.12.1节，“连接接口”。

MySQL now provides more control over the use of compression to minimize the number of bytes sent over connections to the server. MySQL现在提供了对压缩使用的更多控制，以最小化通过连接发送到服务器的字节数。Previously, a given connection was either uncompressed or used the zlib compression algorithm. 以前，给定的连接要么未压缩，要么使用zlib压缩算法。Now, it is also possible to use the zstd algorithm, and to select a compression level for zstd connections. 现在，还可以使用zstd算法，并为zstd连接选择压缩级别。The permitted compression algorithms can be configured on the server side, as well as on the connection-origination side for connections by client programs and by servers participating in source/replica replication or Group Replication. 允许的压缩算法可以在服务器端配置，也可以在连接发起端配置，用于客户端程序和参与源/副本复制或组复制的服务器的连接。For more information, see Section 4.2.8, “Connection Compression Control”.有关更多信息，请参阅第4.2.8节，“连接压缩控制”。

Configuration.配置  The maximum permitted length of host names throughout MySQL has been raised to 255 ASCII characters, up from the previous limit of 60 characters. MySQL中主机名的最大允许长度从以前的60个字符提高到255个ASCII字符。This applies to, for example, host name-related columns in the data dictionary, mysql system schema, Performance Schema, INFORMATION_SCHEMA, and sys schema; the MASTER_HOST value for the CHANGE MASTER TO statement; the Host column in SHOW PROCESSLIST statement output; host names in account names (such as used in account-management statements and in DEFINER attributes); and host name-related command options and system variables.例如，这适用于数据字典、mysql系统模式、性能架构、INFORMATION_SCHEMA和sys模式中与主机名相关的列；CHANGE MASTER TO语句的MASTER_HOST值；SHOW PROCESSLIST语句输出中的Host列；帐户名中的主机名（如用于帐户管理语句和定义器属性）；和主机名相关的命令选项和系统变量。

Caveats:注意事项：

Plugins.插件。  Previously, MySQL plugins could be written in C or C++. 以前，MySQL插件可以用C或C++编写。MySQL header files used by plugins now contain C++ code, which means that plugins must be written in C++, not C.现在插件使用的MySQL头文件包含C++代码，这意味着插件必须用C++编写，而不是C。

C API.C API。  The MySQL C API now supports asynchronous functions for nonblocking communication with the MySQL server. MySQL C API现在支持异步函数，以实现与MySQL服务器的非阻塞通信。Each function is the asynchronous counterpart to an existing synchronous function. 每个函数都是现有同步函数的异步对应项。The synchronous functions block if reads from or writes to the server connection must wait. 如果从服务器连接读取或写入必须等待，则同步函数将阻止。The asynchronous functions enable an application to check whether work on the server connection is ready to proceed. 异步函数使应用程序能够检查服务器连接上的工作是否准备好继续。If not, the application can perform other work before checking again later. 如果没有，应用程序可以在稍后再次检查之前执行其他工作。See C API Asynchronous Interface.请参阅C API异步接口。

Additional target types for casts.强制转换的其他目标类型。  The functions CAST() and CONVERT() now support conversions to types DOUBLE, FLOAT, and REAL. 函数CAST()和CONVERT()现在支持转换为DOUBLE、FLOAT和REAL类型。Added in MySQL 8.0.17. 在MySQL 8.0.17中添加。See Section 12.11, “Cast Functions and Operators”.请参阅第12.11节，“强制转换函数和运算符”。

JSON schema validation.JSON架构验证。  MySQL 8.0.17 adds two functions JSON_SCHEMA_VALID() and JSON_SCHEMA_VALIDATION_REPORT() for validating JSON documents again JSON schemas. MySQL 8.0.17增加了两个函数JSON_SCHEMA_VALID()和JSON_SCHEMA_VALIDATION_REPORT()，用于再次验证JSON文档和JSON模式。JSON_SCHEMA_VALID() returns TRUE (1) if the document validates against the schema and FALSE (0) if it does not. JSON_SCHEMA_VALID()如果文档根据架构进行验证，则返回TRUE（1），否则返回FALSE（0）。JSON_SCHEMA_VALIDATION_REPORT() returns a JSON document containing detailed information about the results of the validation. JSON_SCHEMA_VALIDATION_REPORT()返回一个JSON文档，其中包含有关验证结果的详细信息。The following statements apply to both of these functions:以下语句适用于这两个函数：

See Section 12.18.7, “JSON Schema Validation Functions”, for more information and examples.有关更多信息和示例，请参阅第12.18.7节，“JSON模式验证函数”。

Multi-valued indexes.多值索引。  Beginning with MySQL 8.0.17, InnoDB supports the creation of a multi-valued index, which is a secondary index defined on a JSON column that stores an array of values and which can have multiple index records for a single data record. 从MySQL8.0.17开始，InnoDB支持创建多值索引，它是一个在JSON列上定义的二级索引，存储一个值数组，对于一个数据记录可以有多个索引记录。Such an index uses a key part definition such as CAST(data->'$.zipcode' AS UNSIGNED ARRAY). 这样的索引使用关键部分定义，例如CAST(data->'$.zipcode' AS UNSIGNED ARRAY)。A multi-valued index is used automatically by the MySQL optimizer for suitable queries, as can be viewed in the output of EXPLAIN.多值索引由MySQL优化器自动用于适当的查询，如EXPLAIN的输出所示。

As part of this work, MySQL adds a new function JSON_OVERLAPS() and a new MEMBER OF() operator for working with JSON documents, additionally extending the CAST() function with a new ARRAY keyword, as described in the following list:作为这项工作的一部分，MySQL添加了一个新函数JSON_OVERLAPS()和一个新的MEMBER OF()运算符来处理JSON文档，另外还使用一个新的ARRAY关键字扩展了CAST()函数，如下表所示：

For detailed information about multi-valued indexes, including examples, see Multi-Valued Indexes. 有关多值索引（包括示例）的详细信息，请参阅多值索引。Section 12.18.3, “Functions That Search JSON Values”, provides information about JSON_OVERLAPS() and MEMBER OF(), along with examples of use.第12.18.3节，“搜索JSON值的函数”提供了有关JSON_OVERLAPS()和MEMBER OF()的信息，以及使用示例。

Hintable time_zone.可隐藏的时区。  As of MySQL 8.0.17, the time_zone session variable is hintable using SET_VAR.从MySQL8.0.17开始，time_zone会话变量可以使用SET_VAR隐藏。

Redo Log Archiving.重做日志存档。  As of MySQL 8.0.17, InnoDB supports redo log archiving. 从MySQL8.0.17开始，InnoDB支持重做日志归档。Backup utilities that copy redo log records may sometimes fail to keep pace with redo log generation while a backup operation is in progress, resulting in lost redo log records due to those records being overwritten. 当备份操作正在进行时，复制重做日志记录的备份实用程序有时可能无法跟上重做日志生成的速度，从而导致由于这些记录被覆盖而丢失重做日志记录。The redo log archiving feature addresses this issue by sequentially writing redo log records to an archive file. 重做日志存档功能通过将重做日志记录顺序写入存档文件来解决此问题。Backup utilities can copy redo log records from the archive file as necessary, thereby avoiding the potential loss of data. 备份实用程序可以根据需要从存档文件中复制重做日志记录，从而避免潜在的数据丢失。For more information, see Redo Log Archiving.有关详细信息，请参阅重做日志存档。

The Clone Plugin.克隆插件。  As of MySQL 8.0.17, MySQL provides a clone plugin that permits cloning InnoDB data locally or from a remote MySQL server instance. 从MySQL 8.0.17开始，MySQL提供了一个克隆插件，允许在本地或从远程MySQL服务器实例克隆InnoDB数据。A local cloning operation stores cloned data on the same server or node where the MySQL instance runs. 本地克隆操作将克隆的数据存储在运行MySQL实例的同一服务器或节点上。A remote cloning operation transfers cloned data over the network from a donor MySQL server instance to the recipient server or node where the cloning operation was initiated.远程克隆操作通过网络将克隆数据从提供方MySQL服务器实例传输到发起克隆操作的接收方服务器或节点。

The clone plugin supports replication. 克隆插件支持复制。In addition to cloning data, a cloning operation extracts and transfers replication coordinates from the donor and applies them on the recipient, which enables using the clone plugin for provisioning Group Replication members and replicas. 除了克隆数据之外，克隆操作还从提供方提取和传输复制坐标，并将其应用于接收方，这使得可以使用克隆插件来设置组复制成员和副本。Using the clone plugin for provisioning is considerably faster and more efficient than replicating a large number of transactions. 使用克隆插件进行资源调配要比复制大量事务快得多，效率也更高。Group Replication members can also be configured to use the clone plugin as an alternative method of recovery, so that members automatically choose the most efficient way to retrieve group data from seed members.组复制成员还可以配置为使用克隆插件作为恢复的替代方法，以便成员自动选择从种子成员检索组数据的最有效方式。

For more information, see Section 5.6.7, “The Clone Plugin”, and Section 18.5.3.2, “Cloning for Distributed Recovery”.有关更多信息，请参阅第5.6.7节，“克隆插件”和第18.5.3.2节，“克隆以进行分布式恢复”。

Hash Join Optimization.哈希连接优化。  Beginning with MySQL 8.0.18, a hash join is used whenever each pair of tables in a join includes at least one equi-join condition, and no indexes apply to any join condition. 从MySQL 8.0.18开始，每当连接中的每对表至少包含一个equi连接条件，并且没有索引应用于任何连接条件时，就会使用hash连接。A hash join does not require indexes, although it can be used with indexes applying to single-table predicates only. 哈希联接不需要索引，尽管它可以与仅应用于单表谓词的索引一起使用。A hash join is more efficient in most cases than the block-nested loop algorithm. 哈希连接在大多数情况下比块嵌套循环算法更有效。Joins such as those shown here can be optimized in this manner:此处所示的连接可以通过以下方式进行优化：

SELECT *
    FROM t1
    JOIN t2
        ON t1.c1=t2.c1;

SELECT *
    FROM t1
    JOIN t2
        ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)
    JOIN t3
        ON (t2.c1 = t3.c1)

Hash joins can also be used for Cartesian products—that is, when no join condition is specified.散列联接也可以用于笛卡尔积，也就是说，当没有指定联接条件时。

You can see when the hash join optimization is being used for a particular query using EXPLAIN FORMAT=TREE or EXPLAIN ANALYZE. 您可以使用EXPLAIN FORMAT=TREE或EXPLAIN ANALYZE查看哈希连接优化何时用于特定查询。(In MySQL 8.0.20 and later, you can also use EXPLAIN, omitting FORMAT=TREE.)（在MySQL 8.0.20及更高版本中，还可以使用EXPLAIN，省略FORMAT=TREE。）

The amount of memory available to a hash join is limited by the value of join_buffer_size. 哈希联接可用的内存量受join_buffer_size的值限制。A hash join that requires more than this much memory is executed on disk; the number of disk files that can be used by an on-disk hash join is limited by open_files_limit.在磁盘上执行一个哈希连接，它需要的内存比这个多；磁盘上哈希联接可以使用的磁盘文件数受open_files_limit的限制。

As of MySQL 8.0.19, the hash_join optimizer switch which was introduced in MySQL 8.0.18 no longer supported (hash_join=on still appears as part of the value of optimizer_switch, but setting it no longer has any effect). 从MySQL 8.0.19开始，MySQL 8.0.18中引入的hash_join优化器开关不再受支持（hash_join=on仍然作为optimizer_switch值的一部分出现，但是设置它不再有任何效果）。The HASH_JOIN and NO_HASH_JOIN optimizer hints are also no longer supported. HASH_JOIN和NO_HASH_JOIN优化器提示也不再受支持。The switch and the hint are both now deprecated; expect them to be removed in a future MySQL release. 开关和提示现在都被弃用了；希望在将来的MySQL版本中删除它们。In MySQL 8.0.18 and later, hash joins can be disabled using the NO_BNL optimizer switch.在MySQL 8.0.18及更高版本中，可以使用NO-BNL优化器开关禁用散列联接。

In MySQL 8.0.20 and later, block nested loop is no longer used in the MySQL server, and a hash join is employed any time a block nested loop would have been used previously, even when the query contains no equi-join conditions. 在MySQL 8.0.20及更高版本中，MySQL服务器不再使用块嵌套循环，并且在以前使用块嵌套循环的任何时候都会使用哈希连接，即使查询不包含equi-join条件。This applies to inner non-equijoins, semijoins, antijoins, left outer joins, and right outer joins. 这适用于内部非等分联接、半联接、反联接、左外联接和右外联接。The block_nested_loop flag for the optimizer_switch system variable as well as the BNL and NO_BNL optimizer hints are still supported, but henceforth control use of hash joins only. optimizer_switch系统变量的block_nested_loop标志以及BNL和NO_BNL优化器提示仍受支持，但此后仅控制哈希联接的使用。In addition, both inner and outer joins (including semijoins and antijoins) can now employ batched key access (BKA), which allocates join buffer memory incrementally so that individual queries need not use up large amounts of resources that they do not actually require for resolution. 此外，内部联接和外部联接（包括半联接和反联接）现在都可以采用批处理密钥访问（BKA），它以增量方式分配联接缓冲区内存，这样单个查询就不需要占用它们实际上不需要的大量资源来解决。BKA for inner joins only is supported starting with MySQL 8.0.18.从MySQL8.0.18开始，只支持用于内部联接的BKA。

MySQL 8.0.20 also replaces the executor used in previous versions of MySQL with the iterator executor. MySQL 8.0.20还用迭代器执行器替换了MySQL以前版本中使用的执行器。This work includes replacement of the old index subquery engines that governed queries of the form WHERE value IN (SELECT column FROM table WHERE ...) for those IN queries which have not been optimized as semijoins, as well as queries materialized in the same form, which formerly depended on the old executor.这项工作包括为未被优化为半连接的IN查询替换控制WHERE value IN (SELECT column FROM table WHERE ...)形式的查询的旧的索引子查询引擎，并且查询以相同的形式具体化，以前依赖于旧的执行器。

For more information and examples, see Section 8.2.1.4, “Hash Join Optimization”. 有关更多信息和示例，请参阅第8.2.1.4节，“哈希连接优化”。See also Batched Key Access Joins.另请参阅批量处理密钥访问连接。

EXPLAIN ANALYZE Statement.解释分析语句。  A new form of the EXPLAIN statement, EXPLAIN ANALYZE, is implemented in MySQL 8.0.18, providing expanded information about the execution of SELECT statements in TREE format for each iterator used in processing the query, and making it possible to compare estimated cost with the actual cost of the query. EXPLAIN语句的一种新形式，EXPLAIN ANALYZE在MySQL 8.0.18中实现，它以TREE格式为处理查询时使用的每个迭代器提供了SELECT语句执行的扩展信息，并使比较查询的估计成本和实际成本成为可能。This information includes startup cost, total cost, number of rows returned by this iterator, and the number of loops executed.此信息包括启动成本、总成本、此迭代器返回的行数以及执行的循环数。

In MySQL 8.0.21 and later, this statement also supports a FORMAT=TREE specifier. 在MySQL 8.0.21及更高版本中，此语句还支持FORMAT=TREE说明符。TREE is the only supported format.TREE是唯一受支持的格式。

See Obtaining Information with EXPLAIN ANALYZE, for more information.有关更多信息，请参阅使用解释分析获取信息。

Query cast injection.查询强制类型转换注入。  In version 8.0.18 and later, MySQL injects cast operations into the query item tree inside expressions and conditions in which the data type of the argument and the expected data type do not match. 在版本8.0.18和更高版本中，MySQL将强制转换操作注入到表达式和条件中的查询项树中，在这些表达式和条件中，参数的数据类型和预期的数据类型不匹配。This has no effect on query results or speed of execution, but makes the query as executed equivalent to one which is compliant with the SQL standard while maintaining backwards compatibility with previous releases of MySQL.这对查询结果或执行速度没有影响，但使执行时的查询相当于符合SQL标准的查询，同时保持与MySQL早期版本的向后兼容性。

Such implicit casts are now performed between temporal types (DATE, DATETIME, TIMESTAMP, TIME) and numeric types (SMALLINT, TINYINT, MEDIUMINT, INT/INTEGER, BIGINT; DECIMAL/NUMERIC; FLOAT, DOUBLE, REAL; BIT) whenever they are compared using any of the standard numeric comparison operators (=, >=, >, <, <=, <>/!=, or <=>). 这种隐式转换现在在时态类型（DATE、DATETIME、TIMESTAMP、TIME）和数值类型（SMALLINT、TINYINT、MEDIUMINT、INT/INTEGER、BIGINT；DECIMAL/NUMERIC；FLOAT、DOUBLE、REAL；BIT）使用任何标准数字比较运算符（=、>=、>、<、<=、<>/!=或<=>）进行比较时。In this case, any value that is not already a DOUBLE is cast as one. 在这种情况下，任何尚未为DOUBLE的值都将转换为1。Cast injection is also now performed for comparisons between DATE or TIME values and DATETIME values, where the arguments are cast whenever necessary as DATETIME.现在还可以执行强制转换注入来比较DATE或TIME值与DATETIME值之间的差异，在这种情况下，只要有必要，就可以将参数强制转换为DATETIME。

Beginning with MySQL 8.0.21, such casts are also performed when comparing string types with other types. 从MySQL8.0.21开始，在比较字符串类型和其他类型时也会执行此类强制转换。String types that are cast include CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, and SET. 强制转换的字符串类型包括CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM和SET。When comparing a value of a string type with a numeric type or YEAR, the string cast is to DOUBLE; if the type of the other argument is not FLOAT, DOUBLE, or REAL, it is also cast to DOUBLE. 将字符串类型的值与数字类型或年份进行比较时，字符串类型转换为DOUBLE；如果另一个参数的类型不是FLOAT、DOUBLE或REAL，那么它也会被转换为DOUBLE。When comparing a string type to a DATETIME or TIMESTAMP value, the string is cast is to DATETIME; when comparing a string type with DATE, the string is cast to DATE.将字符串类型与DATETIME或TIMESTAMP值进行比较时，字符串被转换为DATETIME；将字符串类型与DATE进行比较时，字符串将转换为DATE。

It is possible to see when casts are injected into a given query by viewing the output of EXPLAIN ANALYZE, EXPLAIN FORMAT=JSON, or, as shown here, EXPLAIN FORMAT=TREE:可以通过查看EXPLAIN ANALYZE、EXPLAIN FORMAT=JSON或EXPLAIN FORMAT=TREE的输出来查看何时将强制转换注入给定查询：

mysql> CREATE TABLE d (dt DATETIME, d DATE, t TIME);
Query OK, 0 rows affected (0.62 sec)

mysql> CREATE TABLE n (i INT, d DECIMAL, f FLOAT, dc DECIMAL);
Query OK, 0 rows affected (0.51 sec)

mysql> CREATE TABLE s (c CHAR(25), vc VARCHAR(25),
    ->     bn BINARY(50), vb VARBINARY(50), b BLOB, t TEXT,
    ->     e ENUM('a', 'b', 'c'), se SET('x' ,'y', 'z'));
Query OK, 0 rows affected (0.50 sec)

mysql> EXPLAIN FORMAT=TREE SELECT * from d JOIN n ON d.dt = n.i\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (cast(d.dt as double) = cast(n.i as double))
(cost=0.70 rows=1)
    -> Table scan on n  (cost=0.35 rows=1)
    -> Hash
        -> Table scan on d  (cost=0.35 rows=1)

mysql> EXPLAIN FORMAT=TREE SELECT * from s JOIN d ON d.dt = s.c\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (d.dt = cast(s.c as datetime(6)))  (cost=0.72 rows=1)
    -> Table scan on d  (cost=0.37 rows=1)
    -> Hash
        -> Table scan on s  (cost=0.35 rows=1)

1 row in set (0.01 sec)

mysql> EXPLAIN FORMAT=TREE SELECT * from n JOIN s ON n.d = s.c\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (cast(n.d as double) = cast(s.c as double))  (cost=0.70 rows=1)
    -> Table scan on s  (cost=0.35 rows=1)
    -> Hash
        -> Table scan on n  (cost=0.35 rows=1)

1 row in set (0.00 sec)

Such casts can also be seen by executing EXPLAIN [FORMAT=TRADITIONAL], in which case it is also necessary to issue SHOW WARNINGS after executing the EXPLAIN statement.执行EXPLAIN [FORMAT=TRADITIONAL]也可以看到这种类型转换，在这种情况下，在执行EXPLAIN语句之后还需要发出SHOW WARNINGS。

Time zone support for TIMESTAMP and DATETIME.时区支持TIMESTAMP和DATETIME。  As of MySQL 8.0.19, the server accepts a time zone offset with inserted datetime (TIMESTAMP and DATETIME) values. 从MySQL 8.0.19开始，服务器接受带有插入日期时间（TIMESTAMP和DATETIME）值的时区偏移量。This offset uses the same format as that employed when setting the time_zone system variable, except that a leading zero is required when the hours portion of the offset is less than 10, and '-00:00' is not allowed. 此偏移使用的格式与设置时区系统变量时使用的格式相同，只是当偏移的小时数部分小于10时需要前导零，并且不允许使用'-00:00'。Examples of datetime literals that include time zone offsets are '2019-12-11 10:40:30-05:00', '2003-04-14 03:30:00+10:00', and '2020-01-01 15:35:45+05:30'.包含时区偏移的日期时间文字的示例有'2019-12-11 10:40:30-05:00'、'2003-04-14 03:30:00+10:00'和'2020-01-01 15:35:45+05:30'。

Time zone offsets are not displayed when selecting datetime values.选择日期时间值时不显示时区偏移。

Datetime literals incorporating time zone offsets can be used as prepared statement parameter values.包含时区偏移量的Datetime文本可以用作准备语句参数值。

As part of this work, the value used to set the time_zone system variable is now also restricted to the range -13:59 to +14:00, inclusive. 作为这项工作的一部分，用于设置时区系统变量的值现在也被限制在-13:59到+14:00的范围内（包括两者）。(It remains possible to assign name values to time_zone such as 'EST', 'Posix/Australia/Brisbane', and 'Europe/Stockholm' to this variable, provided that the MySQL time zone tables are loaded; see Populating the Time Zone Tables).（仍然可以将time_zone的名称值（如'EST'、'Posix/Australia/Brisbane'和'Europe/Stockholm'分配给此变量），前提是加载了MySQL时区表；请参见填充时区表）。

For more information and examples, see Section 5.1.15, “MySQL Server Time Zone Support”, as well as Section 11.2.2, “The DATE, DATETIME, and TIMESTAMP Types”.有关更多信息和示例，请参阅第5.1.15节，“MySQL Server时区支持”，以及第11.2.2节，“日期、日期时间和时间戳类型”。

Precise information for JSON schema CHECK constraint failures.JSON模式检查约束失败的精确信息。  When using JSON_SCHEMA_VALID() to specify a CHECK constraint, MySQL 8.0.19 and later provides precise information about the reasons for failures of such constraints.当使用JSON_SCHEMA_VALID()指定CHECK约束时，MySQL 8.0.19和更高版本提供了有关此类约束失败原因的精确信息。

For examples and more information, see JSON_SCHEMA_VALID() and CHECK constraints. 有关示例和更多信息，请参阅JSON_SCHEMA_VALID()和检查约束。See also Section 13.1.20.6, “CHECK Constraints”.另请参阅第13.1.20.6节，“检查约束”。

Row and column aliases with ON DUPLICATE KEY UPDATE.行和列别名在重复键更新时具有。  Beginning with MySQL 8.0.19, it is possible to reference the row to be inserted, and, optionally, its columns, using aliases. 从MySQL 8.0.19开始，可以使用别名引用要插入的行，也可以引用其列。Consider the following INSERT statement on a table t having columns a and b:考虑表t中具有列a和b的以下INSERT语句：

INSERT INTO t SET a=9,b=5
    ON DUPLICATE KEY UPDATE a=VALUES(a)+VALUES(b);

Using the alias new for the new row, and, in some cases, the aliases m and n for this row's columns, the INSERT statement can be rewritten in many different ways, some examples of which are shown here:对于新行使用别名new，在某些情况下，对于此行的列使用别名m和n，可以用许多不同的方式重写INSERT语句，其中的一些示例如下所示：

INSERT INTO t SET a=9,b=5 AS new
    ON DUPLICATE KEY UPDATE a=new.a+new.b;

INSERT INTO t VALUES(9,5) AS new
    ON DUPLICATE KEY UPDATE a=new.a+new.b;

INSERT INTO t SET a=9,b=5 AS new(m,n)
    ON DUPLICATE KEY UPDATE a=m+n;

INSERT INTO t VALUES(9,5) AS new(m,n)
    ON DUPLICATE KEY UPDATE a=m+n;

For more information and examples, see Section 13.2.6.2, “INSERT ... ON DUPLICATE KEY UPDATE Statement”.有关更多信息和示例，请参阅第13.2.6.2节，“INSERT ... ON DUPLICATE KEY UPDATE语句”。

SQL standard explicit table clause and table value constructor.SQL标准显式表子句和表值构造函数。  Added table value constructors and explicit table clauses according to the SQL standard. 根据SQL标准添加了表值构造函数和显式表子句。These are implemented in MySQL 8.0.19, respectively, as the TABLE statement and the VALUES statement.它们在MySQL 8.0.19中分别实现为TABLE语句和VALUES语句。

The TABLE statement has the format TABLE table_name, and is equivalent to SELECT * FROM table_name. TABLE语句的格式为TABLE table_name，相当于SELECT * FROM table_name。It supports ORDER BY and LIMIT clauses ( the latter with optional OFFSET), but does not allow for the selection of individual table columns. 它支持ORDER BY子句和LIMIT子句（后者带有可选的OFFSET），但不允许选择单个表列。TABLE can be used anywhere that you would employ the equivalent SELECT statement; this includes joins, unions, INSERT ... SELECT, REPLACE, CREATE TABLE ... SELECT statements, and subqueries. TABLE可以在任何使用等效SELECT语句的地方使用；这包括JOIN、UNION、INSERT ... SELECT语句、REPLACE语句、CREATE TABLE ... SELECT语句和子查询。For example:例如：

VALUES can be used to supply a table value to an INSERT, REPLACE, or SELECT statement, and consists of the VALUES keyword followed by a series of row constructors (ROW()) separated by commas. VALUES可用于向INSERT、REPLACE或SELECT语句提供表值，它由VALUES关键字后跟一系列行构造函数（ROW()）组成，行构造函数之间用逗号分隔。For example, the statement INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9) provides an SQL-compliant equivalent to the MySQL-specific INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9). 例如，INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9)语句提供了一个与SQL兼容的等效语句，相当于MySQL特定的INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9)。You can also select from a VALUES table value constructor just as you would a table, bearing in mind that you must supply a table alias when doing so, and use this SELECT just as you would any other; this includes joins, unions, and subqueries.也可以像从表中选择值一样从VALUES表值构造函数中进行选择，记住这样做时必须提供表别名，并像使用任何其他方法一样使用此SELECT；这包括联接、联合和子查询。

For more information about TABLE and VALUES, and for examples of their use, see the following sections of this documentation:有关TABLE和VALUES的详细信息及其使用示例，请参阅本文档的以下部分：

Optimizer hints for FORCE INDEX, IGNORE INDEX.优化器提示强制索引，忽略索引。  MySQL 8.0 introduces index-level optimizer hints which serve as analogs to the traditional index hints as described in Section 8.9.4, “Index Hints”. MySQL 8.0引入了索引级优化器提示，类似于第8.9.4节，“索引提示”中描述的传统索引提示。The new hints are listed here, along with their FORCE INDEX or IGNORE INDEX equivalents:此处列出了新提示及其FORCE INDEX或IGNORE INDEX等效项：

For example, the following two queries are equivalent:例如，以下两个查询是等效的：

SELECT a FROM t1 FORCE INDEX (i_a) FOR JOIN WHERE a=1 AND b=2;

SELECT /*+ JOIN_INDEX(t1 i_a) */ a FROM t1 WHERE a=1 AND b=2;

The optimizer hints listed previously follow the same basic rules for syntax and usage as existing index-level optimizer hints.前面列出的优化器提示在语法和用法方面遵循与现有索引级优化器提示相同的基本规则。

These optimizer hints are intended to replace FORCE INDEX and IGNORE INDEX, which we plan to deprecate in a future MySQL release, and subsequently to remove from MySQL. 这些优化器提示旨在替换FORCE INDEX和IGNORE INDEX，我们计划在将来的MySQL版本中不推荐使用它们，并随后从MySQL中删除它们。They do not implement a single exact equivalent for USE INDEX; instead, you can employ one or more of NO_INDEX, NO_JOIN_INDEX, NO_GROUP_INDEX, or NO_ORDER_INDEX to achieve the same effect.它们没有实现一个完全等效的USE INDEX；相反，您可以使用一个或多个NO_INDEX、NO_JOIN_INDEX、NO_GROUP_INDEX或NO_ORDER_INDEX来实现相同的效果。

For further information and examples of use, see Index-Level Optimizer Hints.有关更多信息和使用示例，请参阅索引级优化器提示。

JSON_VALUE() function.函数  MySQL 8.0.21 implements a new function JSON_VALUE() intended to simplify indexing of JSON columns. MySQL 8.0.21实现了一个新函数JSON_VALUE()，旨在简化JSON列的索引。In its most basic form, it takes as arguments a JSON document and a JSON path pointing to a single value in that document, as well as (optionally) allowing you to specify a return type with the RETURNING keyword. 在最基本的形式中，它将JSON文档和指向该文档中单个值的JSON路径作为参数，并且（可选）允许您使用RETURNING关键字指定返回类型。JSON_VALUE(json_doc, path RETURNING type) is equivalent to this:相当于：

CAST(
    JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) )
    AS type
);

You can also specify ON EMPTY, ON ERROR, or both clauses, similar to those employed with JSON_TABLE().您还可以指定ON EMPTY子句、ON ERROR子句或两者，类似于JSON_TABLE()中使用的那些子句。

You can use JSON_VALUE() to create an index on an expression on a JSON column like this:可以使用JSON_VALUE()在JSON列上的表达式上创建索引，如下所示：

CREATE TABLE t1(
    j JSON,
    INDEX i1 ( (JSON_VALUE(j, '$.id' RETURNING UNSIGNED)) )
);

INSERT INTO t1 VALUES ROW('{"id": "123", "name": "shoes", "price": "49.95"}');

A query using this expression, such as that shown here, can make use of the index:使用此表达式的查询（如图所示）可以使用索引：

SELECT name, price FROM t1
    WHERE JSON_VALUE(j, '$.id' RETURNING UNSIGNED) = 123;

In many cases, this is simpler than creating a generated column from the JSON column and then creating an index on the generated column.在许多情况下，这比从JSON列创建一个生成的列，然后在生成的列上创建索引要简单。

For more information and examples, see the description of JSON_VALUE().有关更多信息和示例，请参阅JSON_VALUE()的说明。

User comments and user attributes.用户评论和用户属性。  MySQL 8.0.21 introduces the ability to set user comments and user attributes when creating or updating user accounts. MySQL 8.0.21引入了在创建或更新用户帐户时设置用户注释和用户属性的功能。A user comment consists of arbitrary text passed as the argument to a COMMENT clause used with a CREATE USER or ALTER USER statement. 用户注释由作为参数传递给CREATE USER或ALTER USER语句所用的COMMENT子句的任意文本组成。A user attribute consists of data in the form of a JSON object passed as the argument to an ATTRIBUTE clause used with either of these two statements. 用户属性由JSON对象形式的数据组成，JSON对象作为参数传递给与这两条语句一起使用的ATTRIBUTE子句。The attribute can contain any valid key-value pairs in JSON object notation. 该属性可以包含JSON对象表示法中的任何有效键值对。Only one of COMMENT or ATTRIBUTE can be used in a single CREATE USER or ALTER USER statement.在单个CREATE USER或ALTER USER语句中只能使用COMMENT或ATTRIBUTE中的一个。

User comments and user attributes are stored together internally as a JSON object, the comment text as the value of an element having comment as its key. 用户注释和用户属性在内部存储为一个JSON对象，注释文本作为一个元素的值，该元素的键是comment。This information can be retrieved from the ATTRIBUTE column of the INFORMATION_SCHEMA.USER_ATTRIBUTES table; since it is in JSON format, you can use MySQL's JSON function and operators to parse its contents (see Section 12.18, “JSON Functions”). 可以从INFORMATION_SCHEMA.USER_ATTRIBUTES表的ATTRIBUTE列检索此信息；因为它是JSON格式的，所以可以使用MySQL的JSON函数和操作符来解析它的内容（请参阅第12.18节，“JSON函数”）。Successive changes to the user attribute are merged with its current value as when using the JSON_MERGE_PATCH() function.当使用JSON_MERGE_PATCH()函数时，对用户属性的连续更改将与其当前值合并。

Example:例子：

mysql> CREATE USER 'mary'@'localhost' COMMENT 'This is Mary Smith\'s account';
Query OK, 0 rows affected (0.33 sec)

mysql> ALTER USER 'mary'@'localhost'
    -≫     ATTRIBUTE '{"fname":"Mary", "lname":"Smith"}';
Query OK, 0 rows affected (0.14 sec)

mysql> ALTER USER 'mary'@'localhost'
    -≫     ATTRIBUTE '{"email":"mary.smith@example.com"}';
Query OK, 0 rows affected (0.12 sec)

mysql> SELECT
    ->    USER,
    ->    HOST,
    ->    ATTRIBUTE->>"$.fname" AS 'First Name',
    ->    ATTRIBUTE->>"$.lname" AS 'Last Name',
    ->    ATTRIBUTE->>"$.email" AS 'Email',
    ->    ATTRIBUTE->>"$.comment" AS 'Comment'
    -> FROM INFORMATION_SCHEMA.USER_ATTRIBUTES
    -> WHERE USER='mary' AND HOST='localhost'\G
*************************** 1. row ***************************
      USER: mary
      HOST: localhost
First Name: Mary
 Last Name: Smith
     Email: mary.smith@example.com
   Comment: This is Mary Smith's account
1 row in set (0.00 sec)

For more information and examples, see Section 13.7.1.3, “CREATE USER Statement”, Section 13.7.1.1, “ALTER USER Statement”, and Section 26.3.46, “The INFORMATION_SCHEMA USER_ATTRIBUTES Table”.有关更多信息和示例，请参阅第13.7.1.3节，“CREATE USER语句”、第13.7.1.1节，“ALTER USER语句”和第26.3.46节，“信息架构用户属性表”。

New optimizer_switch flags.新的optimizer_switch标志。  MySQL 8.0.21 adds two new flags for the optimizer_switch system variable, as described in the following list:MySQL 8.0.21为optimizer_switch系统变量添加了两个新标志，如下表所示：

For more information, see Section 8.9.2, “Switchable Optimizations”. 有关更多信息，请参阅第8.9.2节，“可切换优化”。See also Section 8.2.1.19, “LIMIT Query Optimization”, Section 8.2.2.1, “Optimizing IN and EXISTS Subquery Predicates with Semijoin Transformations”, and Section 8.2.2.4, “Optimizing Derived Tables, View References, and Common Table Expressions with Merging or Materialization”.另请参阅第8.2.1.19节，“限制查询优化”、第8.2.2.1节，“使用半联接转换优化IN和EXISTS子查询谓词”和第8.2.2.4节，“使用合并或物化优化派生表、视图引用和公共表表达式”。

XML enhancements.XML增强功能。  As of MySQL 8.0.21, the LOAD XML statement now supports CDATA sections in the XML to be imported.从MySQL 8.0.21开始，LOAD XML语句现在支持导入XML中的CDATA部分。

Casting to the YEAR type now supported.现在支持转换为年份类型。  Beginning with MySQL 8.0.22, the server allows casting to YEAR. 从MySQL8.0.22开始，服务器允许YEAR进行强制转换。Both the CAST() and CONVERT() functions support single-digit, two-digit, and four-digit YEAR values. CAST()和CONVERT()函数都支持一位数、两位数和四位数的年份值。For one-digit and two-digit values, the allowed range is 0-99. 对于一位数和两位数的值，允许的范围是0-99。Four-digit values must be in the range 1901-2155. 四位数的值必须在1901-2155之间。YEAR can also be used as the return type for the JSON_VALUE() function; this function supports four-digit years only.YEAR也可以用作JSON_VALUE()函数的返回类型；此函数仅支持四位数年份。

String, time-and-date, and floating-point values can all be cast to YEAR. 字符串、时间和日期以及浮点值都可以转换为YeAR。Casting of GEOMETRY values to YEAR is not supported.不支持将GEOMETRY值强制转换为YEAR。

For more information, including conversion rules, see the description of the CONVERT() function.有关更多信息（包括转换规则），请参阅CONVERT()函数的说明。

Retrieval of TIMESTAMP values as UTC.以UTC格式检索时间戳值。  MySQL 8.0.22 and later supports conversion of a TIMESTAMP column value from the system time zone to a UTC DATETIME on retrieval, using CAST(value AT TIME ZONE specifier AS DATETIME), where the specifier is one of [INTERVAL] '+00:00' or 'UTC'. MySQL 8.0.22及更高版本支持在检索时将TIMESTAMP列值从系统时区转换为UTCDATETIME，使用CAST(value AT TIME ZONE specifier AS DATETIME)，其中说明符为[INTERVAL] '+00:00'或'UTC'之一。The precision of the DATETIME value returned by the cast can be specified up to 6 decimal places, if desired. 如果需要，可以将强制转换返回的DATETIME值的精度指定为最多6位小数。The ARRAY keyword is not supported with this construct.此构造不支持ARRAY关键字。

TIMESTAMP values inserted into a table using a timezone offset are also supported. 还支持使用时区偏移量插入到表中的TIMESTAMP值。Use of AT TIME ZONE is not supported for CONVERT() or any other MySQL function or construct.CONVERT()或任何其他MySQL函数或构造都不支持使用AT TIME ZONE。

For further information and examples, see the description of the CAST() function.有关更多信息和示例，请参见CAST()函数的说明。

Dump file output synchronization.转储文件输出同步。  MySQL 8.0.22 and later supports periodic synchronization when writing to files by SELECT INTO DUMPFILE and SELECT INTO OUTFILE statements. MySQL 8.0.22及更高版本支持SELECT INTO DUMPFILE语句和SELECT INTO OUTFILE语句写入文件时的定期同步。This can be enabled by setting the select_into_disk_sync system variable to ON; the size of the write buffer is determined by the value set for select_into_buffer_size; the default is 131072 (2¹⁷) bytes.这可以通过将select_into_disk_sync系统变量设置为ON来启用；写入缓冲区的大小由select_into_buffer_size设置的值决定；默认值为131072(2¹⁷)字节。

In addition, an optional delay following synchronization to disk can be set using select_into_disk_sync_delay; the default is no delay (0 milliseconds).此外，同步到磁盘后的可选延迟可以使用select_into_disk_sync_delay设置；默认值为无延迟（0毫秒）。

For more information, see the descriptions of the variables referenced previously in this item.有关更多信息，请参阅本项目前面引用的变量说明。

Single preparation of statements.单独编制报表。  As of MySQL 8.0.22, a prepared statement is prepared a single time, rather than once each time it is executed. 从MySQL 8.0.22开始，prepared语句只准备一次，而不是每次执行一次。This is done when executing PREPARE. 这是在执行PREPARE时完成的。This is also true for any statement inside a stored procedure; the statement is prepared once, when the stored procedure is first executed.对于存储过程中的任何语句也是如此；当存储过程第一次执行时，语句准备一次。

One result of this change is that the fashion in which dynamic parameters used in prepared statements are resolved is also changed in the ways listed here:这种变化的一个结果是，已准备语句中使用的动态参数的解析方式也发生了变化，如下所示：

Preparing a statement used as a prepared statement or within a stored procedure only once enhances the performance of the statement, since it negates the added cost of repeated preparation. 只准备一次用作已准备语句或在存储过程中使用的语句就可以提高语句的性能，因为这样可以抵消重复准备所增加的成本。Doing so also avoids possible multiple rollbacks of preparation structures, which has been the source of numerous issues in MySQL.这样做还可以避免可能的准备结构的多次回滚，这一直是MySQL中许多问题的根源。

For more information, see Section 13.5.1, “PREPARE Statement”.有关更多信息，请参阅第13.5.1节，“PREPARE语句”。

RIGHT JOIN as LEFT JOIN handling.右连接作为左连接处理。  As of MySQL 8.0.22, the server handles all instances of RIGHT JOIN internally as LEFT JOIN, eliminating a number of special cases in which a complete conversion was not performed at parse time.从MySQL 8.0.22开始，服务器将RIGHT JOIN的所有实例作为LEFT JOIN在内部处理，消除了一些在解析时没有执行完全转换的特殊情况。

Derived condition pushdown optimization.导出条件下推优化。  MySQL 8.0.22 (and later) implements derived condition pushdown for queries having materialized derived tables. MySQL8.0.22（及更高版本）为具有物化派生表的查询实现派生条件下推。For a query such as SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constant, it is now possible in many cases to push the the outer WHERE condition down to the derived table, in this case resulting in SELECT * FROM (SELECT i, j FROM t1 WHERE i > constant) AS dt.对于SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i > constant之类的查询，在很多情况下现在能够将外部的WHERE条件下推到派生表，在这种情况下导致SELECT * FROM (SELECT i, j FROM t1 WHERE i > constant) AS dt。

Previously, if the derived table was materialized and not merged, MySQL materialized the entire table, then qualified the rows with the WHERE condition. 以前，如果派生表是具体化的而不是合并的，MySQL具体化整个表，然后用WHERE条件限定行。Moving the WHERE condition into the subquery using the derived condition pushdown optimization can often reduce the number of rows must be be processed, which can decrease the time needed to execute the query.使用派生条件下推优化将WHERE条件移动到子查询中通常可以减少必须处理的行数，从而减少执行查询所需的时间。

An outer WHERE condition can be pushed down directly to a materialized derived table when the derived table does not use any aggregate or window functions. 当派生表不使用任何聚合或窗口函数时，可以将外部WHERE条件直接下推到具体化的派生表。When the derived table has a GROUP BY and does not use any window functions, the outer WHERE condition can be pushed down to the derived table as a HAVING condition. 当派生表具有GROUP BY且不使用任何窗口函数时，可以将外部WHERE条件作为HAVING条件下推到派生表。The WHERE condition can also be pushed down when the derived table uses a window function and the outer WHERE references columns used in the window function's PARTITION clause.当派生表使用窗口函数和窗口函数的PARTITION子句中使用的外部WHERE引用列时，WHERE条件也可以向下推。

Derived condition pushdown is enabled by default, as indicated by the optimizer_switch system variable's derived_condition_pushdown flag. 默认情况下启用派生条件下推，如optimizer_switch系统变量的derived_condition_pushdown标志所示。The flag, added in MySQL 8.0.22, is set to on by default; to disable the optimization for a specific query, you can use the NO_DERIVED_CONDITION_PUSHDOWN optimizer hint (also added in MySQL 8.0.22). MySQL 8.0.22中添加的标志，默认设置为on；要禁用对特定查询的优化，可以使用NO_DERIVED_CONDITION_PUSHDOWN优化器提示（也在MySQL 8.0.22中添加）。If the optimization is disabled due to derived_condition_pushdown being set to off, you can enable it for a given query using DERIVED_CONDITION_PUSHDOWN.如果由于derived_condition_pushdown设置为off而禁用了优化，则可以使用DERIVED_CONDITION_PUSHDOWN为给定查询启用它。

The derived condition pushdown optimization cannot be employed for a derived table that contains a UNION or LIMIT clause. 派生条件下推优化不能用于包含UNION或LIMIT子句的派生表。In addition, a condition that itself uses a subquery cannot be pushed down, and a WHERE condition cannot be pushed down to a derived table that is also an inner table of an outer join. 此外，不能将本身使用子查询的条件下推，也不能将WHERE条件下推到同时也是外部联接的内部表的派生表中。For additional information and examples, see Section 8.2.2.5, “Derived Condition Pushdown Optimization”.有关更多信息和示例，请参阅第8.2.2.5节，“导出条件下推优化”。

Non-locking reads on MySQL grant tables.MySQL授权表上的非锁定读取。  As of MySQL 8.0.22, to permit concurrent DML and DDL operations on MySQL grant tables, read operations that previously acquired row locks on MySQL grant tables are executed as non-locking reads.从MySQL 8.0.22开始，为了允许在MySQL grant表上同时执行DML和DDL操作，以前在MySQL grant表上获得行锁的读取操作将作为非锁定读取执行。

The operations that are now performed as non-locking reads on MySQL grant tables include:现在在MySQL grant表上作为非锁定读取执行的操作包括：

For additional information, see Grant Table Concurrency.有关其他信息，请参阅授权表并发。

The utf8mb3 character set is deprecated. Please use utf8mb4 instead.不推荐使用utf8mb3字符集。请改用utf8mb4。

Because caching_sha2_password is the default authentication plugin in MySQL 8.0 and provides a superset of the capabilities of the sha256_password authentication plugin, sha256_password is deprecated; expect it to be removed in a future version of MySQL. 因为caching_sha2_password是MySQL 8.0中的默认身份验证插件，并且提供了sha256_password身份验证插件功能的超集，所以不推荐使用sha256_password；希望在MySQL的未来版本中删除它。MySQL accounts that authenticate using sha256_password should be migrated to use caching_sha2_password instead.使用sha256_password进行身份验证的MySQL帐户应该迁移为使用caching_sha2_password。

The validate_password plugin has been reimplemented to use the component infrastructure. validate_password插件已被重新实现以使用组件基础结构。The plugin form of validate_password is still available but is now deprecated; expect it to be removed in a future version of MySQL. validate_password的插件形式仍然可用，但现在已被弃用；希望在MySQL的未来版本中删除它。MySQL installations that use the plugin should make the transition to using the component instead. 使用插件的MySQL安装应该转换为使用组件。See Section 6.4.3.3, “Transitioning to the Password Validation Component”.请参阅第6.4.3.3节，“转换到密码验证组件”。

The ENGINE clause for the ALTER TABLESPACE and DROP TABLESPACE statements is deprecated.ALTER TABLESPACE语句和DROP TABLESPACE语句的ENGINE子句已弃用。

The PAD_CHAR_TO_FULL_LENGTH SQL mode is deprecated.SQL模式PAD_CHAR_TO_FULL_LENGTH被建议弃用了。

AUTO_INCREMENT support is deprecated for columns of type FLOAT and DOUBLE (and any synonyms). 对于FLOAT和DOUBLE（以及任何同义词）类型的列，不推荐使用自动增量支持。Consider removing the AUTO_INCREMENT attribute from such columns, or convert them to an integer type.考虑从这些列中删除AUTO_INCREMENT属性，或将它们转换为整数类型。

The UNSIGNED attribute is deprecated for columns of type FLOAT, DOUBLE, and DECIMAL (and any synonyms). 对于FLOAT、DOUBLE和DECIMAL（以及任何同义词）类型的列，不推荐使用UNSIGNED属性。Consider using a simple CHECK constraint instead for such columns.考虑使用一个简单的CHECK约束来代替这样的列。

FLOAT(M,D) and DOUBLE(M,D) syntax to specify the number of digits for columns of type FLOAT and DOUBLE (and any synonyms) is a nonstandard MySQL extension. FLOAT(M,D)语法DOUBLE(M,D)语法指定FLOAT和DOUBLE类型的列（以及任何同义词）的位数是一个非标准的MySQL扩展。This syntax is deprecated.此语法已弃用。

The ZEROFILL attribute is deprecated for numeric data types, as is the display width attribute for integer data types. 对于数字数据类型，ZEROFILL属性不受欢迎，对于整数数据类型，显示宽度属性也不受欢迎。Consider using an alternative means of producing the effect of these attributes. 考虑使用一种替代方法来产生这些属性的效果。For example, applications could use the LPAD() function to zero-pad numbers up to the desired width, or they could store the formatted numbers in CHAR columns.例如，应用程序可以使用LPAD()函数将填充数字归零到所需的宽度，也可以将格式化的数字存储在CHAR列中。

For string data types, the BINARY attribute is a nonstandard MySQL extension that is shorthand for specifying the binary (_bin) collation of the column character set (or of the table default character set if no column character set is specified). 对于字符串数据类型，BINARY属性是一个非标准的MySQL扩展，它是指定列字符集（如果未指定列字符集，则为表默认字符集）的二进制（_bin）排序规则的缩写。In MySQL 8.0, this nonstandard use of BINARY is ambiguous because the utf8mb4 character set has multiple _bin collations, so the BINARY attribute is deprecated; expect support for it to be removed in a future version of MySQL. 在MySQL 8.0中，BINARY的这种非标准用法是不明确的，因为utf8mb4字符集有多个_bin排序规则，所以BINARY属性不受欢迎；在MySQL的未来版本中，对它的支持可能会被删除。Applications should be adjusted to use an explicit _bin collation instead.应用程序应该调整为使用显式的_bin排序规则。

The use of BINARY to specify a data type or character set remains unchanged.使用BINARY指定数据类型或字符集保持不变。

The nonstandard C-style &&, ||, and ! operators that are synonyms for the standard SQL AND, OR, and NOT operators, respectively, are deprecated. 非标准C样式的&&、||，还有!分别作为标准SQLAND、OR和NOT运算符同义词的运算符将被弃用。Applications that use the nonstandard operators should be adjusted to use the standard operators.使用非标准运算符的应用程序应调整为使用标准运算符。

The JSON_MERGE() function is deprecated. 不推荐使用JSON_MERGE()函数。Use JSON_MERGE_PRESERVE() instead.请改用JSON_MERGE_PRESERVE()。

The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated. 不推荐使用SQL_CALC_FOUND_ROWS查询修饰符和附带的FOUND_ROWS()函数。See the FOUND_ROWS() description for information about an alternative strategy.有关替代策略的信息，请参阅find_ROWS()说明。

Support for TABLESPACE = innodb_file_per_table and TABLESPACE = innodb_temporary clauses with CREATE TEMPORARY TABLE is deprecated as of MySQL 8.0.13.从MySQL8.0.13开始，不推荐支持TABLESPACE = innodb_file_per_table子句和TABLESPACE = innodb_temporary子句配合CREATE TEMPORARY TABLE。

For SELECT statements, use of an INTO clause after FROM but not at the end of the SELECT is deprecated as of MySQL 8.0.20. 对于SELECT语句，从MySQL8.0.20开始，不推荐在FROM后面而不是SELECT末尾使用INTO子句。It is preferred to place the INTO at the end of the statement.最好将INTO放在语句末尾。

For UNION statements, these two variants containing INTO are deprecated as of MySQL 8.0.20:对于UNION语句，从MySQL 8.0.20开始，这两个包含INTO的变体就不再推荐了：

See Section 13.2.10.1, “SELECT ... INTO Statement”, and Section 13.2.10.3, “UNION Clause”.请参阅第13.2.10.1节，“SELECT ... INTO 语句”和第13.2.10.3节，“UNION子句”。

FLUSH HOSTS is deprecated as of MySQL 8.0.23. 从MySQL8.0.23开始，不推荐使用FLUSH HOSTS。Instead, truncate the Performance Schema host_cache table:而是截断性能架构host_cache表：

TRUNCATE TABLE performance_schema.host_cache;

The TRUNCATE TABLE operation requires the DROP privilege for the table.TRUNCATE TABLE操作需要表的DROP权限。

The mysql_upgrade client is deprecated because its capabilities for upgrading the system tables in the mysql system schema and objects in other schemas have been moved into the MySQL server. 不推荐使用mysql_upgrade客户端，因为它升级mysql系统模式中的系统表和其他模式中的对象的功能已被移到MySQL服务器中。See Section 2.11.3, “What the MySQL Upgrade Process Upgrades”.请参阅第2.11.3节，“MySQL升级过程升级了什么”。

The --no-dd-upgrade server option is deprecated. 不推荐使用--no-dd-upgrade服务器选项。It is superseded by the --upgrade option, which provides finer control over data dictionary and server upgrade behavior.它被--upgrade选项取代，后者提供了对数据字典和服务器升级行为的更精细的控制。

The mysql_upgrade_info file, which is created data directory and used to store the MySQL version number, is deprecated; expect it to be removed in a future version of MySQL.mysql_upgrade_info文件创建于数据目录，用于存储MySQL版本号，不推荐使用；希望在MySQL的未来版本中删除它。

The relay_log_info_file system variable and --master-info-file option are deprecated. relay_log_info_file系统变量和--master-info-file选项已弃用。Previously, these were used to specify the name of the relay log info log and source info log when relay_log_info_repository=FILE and master_info_repository=FILE were set, but those settings have been deprecated. 以前，当设置relay_log_info_repository=FILE和master_info_repository=FILE时，它们用于指定中继日志信息日志和源信息日志的名称，但这些设置已被弃用。The use of files for the relay log info log and source info log has been superseded by crash-safe replica tables, which are the default in MySQL 8.0.中继日志信息日志和源信息日志文件的使用已经被崩溃安全副本表所取代，这是MySQL 8.0中的默认值。

The max_length_for_sort_data system variable is now deprecated due to optimizer changes that make it obsolete and of no effect.max_length_for_sort_data系统变量现在已被弃用，因为优化器的更改使其过时且无效。

These legacy parameters for compression of connections to the server are deprecated: The --compress client command-line option; the MYSQL_OPT_COMPRESS option for the mysql_options() C API function; the slave_compressed_protocol system variable. 不推荐使用这些用于压缩到服务器的连接的旧参数：--compress客户端命令行选项；MYSQL_options()C API函数的MYSQL_OPT_COMPRESS选项；slave_compressed_protocol系统变量。For information about parameters to use instead, see Section 4.2.8, “Connection Compression Control”.有关要使用的参数的信息，请参阅第4.2.8节，“连接压缩控制”。

Use of the MYSQL_PWD environment variable to specify a MySQL password is deprecated.不赞成使用MYSQL_PWD环境变量指定MYSQL密码。

Use of VALUES() to access new row values in INSERT ... ON DUPLICATE KEY UPDATE is deprecated as of MySQL 8.0.20. 使用VALUES()访问INSERT ... ON DUPLICATE KEY UPDATE中的新行值从MySQL 8.0.20开始不推荐使用。Use aliases for the new row and columns, instead.请为新行和新列改用别名。

Because specifying ON ERROR before ON EMPTY when invoking JSON_TABLE() is counter to the SQL standard, this syntax is now deprecated in MySQL. 因为在调用JSON_TABLE()时在ON EMPTY前面指定ON ERROR与SQL标准背道而驰，所以MySQL现在不赞成使用这种语法。Beginning with MySQL 8.0.20, the server prints a warning whenever you attempt to do so. 从MySQL 8.0.20开始，每当您尝试这样做时，服务器都会打印一条警告。When specifying both of these clauses in a single JSON_TABLE() invocation, make sure that ON EMPTY is used first.在单个JSON_TABLE()调用中指定这两个子句时，请确保首先使用ON EMPTY。

Columns with index prefixes have never been supported as part of a table's partitioning key; previously, these were allowed when creating, altering, or upgrading partitioned tables but were excluded by the table's partitioning function, and no warning that this had occurred was issued by the server. 带有索引前缀的列从未被支持作为表分区键的一部分；以前，在创建、更改或升级分区表时，这些是允许的，但被表的分区函数排除在外，并且服务器不会发出发生这种情况的警告。This permissive behavior is now deprecated, and subject to removal in a future version of MySQL in which using any such columns in the partitioning key causes the CREATE TABLE or ALTER TABLE statement in they occur to be rejected.这种允许的行为现在已经被弃用，并且在MySQL的未来版本中可能会被删除，在将来的版本中，在分区键中使用任何这样的列都会导致其中的CREATE TABLE或ALTER TABLE语句被拒绝。

As of MySQL 8.0.21, whenever columns using index prefixes are specified as part of the partitioning key, a warning is generated for each such column. 从MySQL8.0.21开始，每当使用索引前缀的列被指定为分区键的一部分时，就会为每个这样的列生成一个警告。Whenever a CREATE TABLE or ALTER TABLE statement is rejected because all columns in the proposed partitioning key would have index prefixes, the resulting error now provides the exact reason for the rejection. 每当CREATE TABLE或ALTER TABLE语句因为建议的分区键中的所有列都有索引前缀而被拒绝时，现在产生的错误提供了拒绝的确切原因。In either instance, this includes cases in which the columns used in the partitioning function are defined implicitly as those in the table's primary key by employing an empty PARTITION BY KEY() clause.在任何一种情况下，这都包括这样的情况：通过使用空PARTITION BY KEY()子句，将分区函数中使用的列隐式定义为表主键中的列。

For more information and examples, see Column index prefixes not supported for key partitioning.有关更多信息和示例，请参阅键分区不支持的列索引前缀。

The InnoDB memcached plugin is deprecated as of MySQL 8.0.22; expect support for it to be removed in a future version of MySQL.InnoDB memcached插件从MySQL8.0.22开始被弃用；在MySQL的未来版本中，对它的支持可能会被删除。

The temptable_use_mmap variable is now deprecated as of MySQL 8.0.26; expect support for it to be removed in a future version of MySQL.从MySQL8.0.26开始，temptable_use_mmap变量现在已经被弃用了；在MySQL的未来版本中，对它的支持可能会被删除。

The innodb_locks_unsafe_for_binlog system variable was removed. innodb_locks_unsafe_for_binlog系统变量已删除。The READ COMMITTED isolation level provides similar functionality.READ COMMITTED隔离级别提供了类似的功能。

The information_schema_stats variable, introduced in MySQL 8.0.0, was removed and replaced by information_schema_stats_expiry in MySQL 8.0.3.MySQL 8.0.0中引入的information_schema_stats变量已被删除，并替换为MySQL 8.0.3中的information_schema_stats_expiry。

information_schema_stats_expiry defines an expiration setting for cached INFORMATION_SCHEMA table statistics. information_schema_stats_expiry定义缓存的INFORMATION_SCHEMA表统计的过期设置。For more information, see Section 8.2.3, “Optimizing INFORMATION_SCHEMA Queries”.有关更多信息，请参阅第8.2.3节，“优化信息和模式查询”。

Code related to obsoleted InnoDB system tables was removed in MySQL 8.0.3. MySQL8.0.3中删除了过时的InnoDB系统表的相关代码。INFORMATION_SCHEMA views based on InnoDB system tables were replaced by internal system views on data dictionary tables. 将基于InnoDB系统表的INFORMATION_SCHEMA视图替换为数据字典表的内部系统视图。Affected InnoDB INFORMATION_SCHEMA views were renamed:受影响的InnoDB INFORMATION_SCHEMA视图已重命名：

After upgrading to MySQL 8.0.3 or later, update any scripts that reference previous InnoDB INFORMATION_SCHEMA view names.升级到MySQL 8.0.3或更高版本后，请更新引用以前InnoDB INFORMATION_SCHEMA视图名称的所有脚本。

The following features related to account management are removed:以下与帐户管理相关的功能将被删除：

The query cache was removed. Removal includes these items:已删除查询缓存。拆除包括以下项目：

These deprecated query cache items remain deprecated, but have no effect; expect them to be removed in a future MySQL release:这些不推荐使用的查询缓存项仍然不推荐使用，但没有任何效果；希望在将来的MySQL版本中删除它们：

The have_query_cache system variable remains deprecated, and always has a value of NO; expect it to be removed in a future MySQL release.have_query_cache系统变量仍然不推荐使用，并且始终具有值NO；希望在将来的MySQL版本中删除它。

The data dictionary provides information about database objects, so the server no longer checks directory names in the data directory to find databases. 数据字典提供有关数据库对象的信息，因此服务器不再检查数据目录中的目录名来查找数据库。Consequently, the --ignore-db-dir option and ignore_db_dirs system variables are extraneous and are removed.因此，--ignore-db-dir选项和ignore_db_dirs系统变量是无关的，将被删除。

The DDL log, also known as the metadata log, has been removed. DDL日志（也称为元数据日志）已被删除。Beginning with MySQL 8.0.3, this functionality is handled by the data dictionary innodb_ddl_log table. 从MySQL 8.0.3开始，这个功能由数据字典innodb_ddl_log表处理。See Viewing DDL Logs.请参阅查看DDL日志。

The tx_isolation and tx_read_only system variables have been removed. tx_isolation和tx_read_only系统变量已删除。Use transaction_isolation and transaction_read_only instead.改用transaction_isolation和transaction_read_only。

The sync_frm system variable has been removed because .frm files have become obsolete.sync_frm系统变量已被删除，因为.frm文件已过时。

The secure_auth system variable and --secure-auth client option have been removed. secure_auth系统变量和--secure-auth客户端选项已被删除。The MYSQL_SECURE_AUTH option for the mysql_options() C API function was removed.MYSQL_options()C API函数的MYSQL_SECURE_AUTH选项已删除。

The multi_range_count system variable is removed.multi_range_count系统变量被删除。

The log_warnings system variable and --log-warnings server option have been removed. 已删除log_warnings系统变量和--log warnings服务器选项。Use the log_error_verbosity system variable instead.请改用log_error_verbosity系统变量。

The global scope for the sql_log_bin system variable was removed. sql_log_bin系统变量的全局作用域已删除。sql_log_bin has session scope only, and applications that rely on accessing @@GLOBAL.sql_log_bin should be adjusted.sql_log_bin只有会话作用域，应该调整依赖于访问@@GLOBAL.sql_log_bin的应用程序。

The metadata_locks_cache_size and metadata_locks_hash_instances system variables are removed.metadata_locks_cache_size和metadata_locks_hash_instances系统变量将被删除。

The unused date_format, datetime_format, time_format, and max_tmp_tables system variables are removed.未使用的date_format、datetime_format、time_format和max_tmp_tables系统变量将被删除。

These deprecated compatibility SQL modes are removed: DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS. 这些不推荐使用的兼容SQL模式被删除：DB2、MAXDB、MSSQL、MYSQL323、MYSQL40、ORACLE、POSTGRESQL、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_TABLE_OPTIONS。They can no longer be assigned to the sql_mode system variable or used as permitted values for the mysqldump --compatible option.它们不能再分配给sql_mode系统变量或用作mysqldump--compatible选项的允许值。

Removal of MAXDB means that the TIMESTAMP data type for CREATE TABLE or ALTER TABLE is treated as TIMESTAMP, and is no longer treated as DATETIME.删除MAXDB意味着CREATE TABLE或ALTER TABLE的TIMESTAMP数据类型被视为TIMESTAMP，不再被视为DATETIME。

The deprecated ASC or DESC qualifiers for GROUP BY clauses are removed. GROUP BY子句的已弃用的ASC或DESC限定符将被删除。Queries that previously relied on GROUP BY sorting may produce results that differ from previous MySQL versions. 以前依赖GROUP BY排序的查询可能会产生不同于以前MySQL版本的结果。To produce a given sort order, provide an ORDER BY clause.要生成给定的排序顺序，请提供ORDER BY子句。

The EXTENDED and PARTITIONS keywords for the EXPLAIN statement have been removed. EXPLAIN语句的EXTENDED和PARTITIONS关键字已被删除。These keywords are unnecessary because their effect is always enabled.这些关键字是不必要的，因为它们的效果始终是启用的。

These encryption-related items are removed:这些与加密相关的项目将被删除：

In place of the removed encryption functions: For ENCRYPT(), consider using SHA2() instead for one-way hashing. 代替加密函数：对于ENCRYPT()，考虑改用ShA2()，而不是单向散列。For the others, consider using AES_ENCRYPT() and AES_DECRYPT() instead.对于其他的，考虑改用AES_ENCRYPT()和AES_DECRYPT()。

In MySQL 5.7, several spatial functions available under multiple names were deprecated to move in the direction of making the spatial function namespace more consistent, the goal being that each spatial function name begin with ST_ if it performs an exact operation, or with MBR if it performs an operation based on minimum bounding rectangles. 在MySQL5.7中，不推荐使用多个名称下的多个可用空间函数，以使空间函数名称空间更加一致，目标是如果每个空间函数名称执行精确的操作，则以ST_开头；如果每个空间函数名称执行基于最小边界矩形的操作，则以MBR开头。In MySQL 8.0, the deprecated functions are removed to leave only the corresponding ST_ and MBR functions:在MySQL 8.0中，不推荐使用的函数被删除，只保留相应的ST_和MBR函数：

The functions described in Section 12.17.4, “Functions That Create Geometry Values from WKB Values” previously accepted either WKB strings or geometry arguments. 第12.17.4节，“从WKB值创建几何值的函数”中描述的函数以前接受WKB字符串或几何参数。Geometry arguments are no longer permitted and produce an error. 几何参数不再被允许并产生错误。See that section for guidelines for migrating queries away from using geometry arguments.有关从使用几何参数迁移查询的指导原则，请参见该部分。

The parser no longer treats \N as a synonym for NULL in SQL statements. 分析器不再将\N视为SQL语句中NULL的同义词。Use NULL instead.请改用NULL。

This change does not affect text file import or export operations performed with LOAD DATA or SELECT ... INTO OUTFILE, for which NULL continues to be represented by \N. 此更改不影响使用LOAD DATA或SELECT ... INTO OUTFILE执行的文本文件导入或导出操作，其中NULL继续由\N表示。See Section 13.2.7, “LOAD DATA Statement”.请参阅第13.2.7节，“LOAD DATA语句”。

PROCEDURE ANALYSE() syntax is removed.PROCEDURE ANALYSE()语法已被删除。

The client-side --ssl and --ssl-verify-server-cert options have been removed. 客户端--ssl和--ssl-verify-server-cert选项已被删除。Use --ssl-mode=REQUIRED instead of --ssl=1 or --enable-ssl. 请使用--ssl-mode=REQUIRED而不是--ssl=1或--enable-ssl。Use --ssl-mode=DISABLED instead of --ssl=0, --skip-ssl, or --disable-ssl. 使用--ssl-mode=DISABLED而不是--ssl=0、--skip-ssl或--disable-ssl。Use --ssl-mode=VERIFY_IDENTITY instead of --ssl-verify-server-cert options. 使用--ssl-mode=VERIFY_IDENTITY而不是--ssl-verify-server-cert选项。(The server-side --ssl option is still available, but is deprecated as of MySQL 8.0.26 and subject to removal in a future MySQL version.)（服务器端--ssl选项仍然可用，但从MySQL8.0.26开始就不推荐使用，在将来的MySQL版本中可能会被删除。）

For the C API, MYSQL_OPT_SSL_ENFORCE and MYSQL_OPT_SSL_VERIFY_SERVER_CERT options for mysql_options() correspond to the client-side --ssl and --ssl-verify-server-cert options and are removed. 对于C API，针对MYSQL_options()的MYSQL_OPT_SSL_ENFORCE和MYSQL_OPT_SSL_VERIFY_SERVER_CERT选项对应于客户端--ssl选项和--ssl-verify-server-cert选项，并且已被删除。Use MYSQL_OPT_SSL_MODE with an option value of SSL_MODE_REQUIRED or SSL_MODE_VERIFY_IDENTITY instead.使用选项值为SSL_MODE_REQUIRED或SSL_MODE_VERIFY_IDENTITY的MYSQL_OPT_SSL_MODE。

The --temp-pool server option was removed.已删除--temp-pool服务器选项。

The ignore_builtin_innodb system variable is removed.已删除ignore_builtin_innodb系统变量。

The server no longer performs conversion of pre-MySQL 5.1 database names containing special characters to 5.1 format with the addition of a #mysql50# prefix. 服务器不再执行将包含特殊字符的MySQL5.1之前版本的数据库名称转换为5.1格式，并添加一个#mysql50#前缀。Because these conversions are no longer performed, the --fix-db-names and --fix-table-names options for mysqlcheck, the UPGRADE DATA DIRECTORY NAME clause for the ALTER DATABASE statement, and the Com_alter_db_upgrade status variable are removed.由于不再执行这些转换，mysqlcheck的--fix-db-namest选项和--fix-table-names选项、ALTER DATABASE语句的UPGRADE DATA DIRECTORY NAME子句以及Com_alter_db_upgrade状态变量都被删除。

Upgrades are supported only from one major version to another (for example, 5.0 to 5.1, or 5.1 to 5.5), so there should be little remaining need for conversion of older 5.0 database names to current versions of MySQL. 只支持从一个主版本升级到另一个主版本（例如，5.0到5.1，或5.1到5.5），因此应该不需要将旧的5.0数据库名称转换为当前版本的MySQL。As a workaround, upgrade a MySQL 5.0 installation to MySQL 5.1 before upgrading to a more recent release.作为一种解决方法，请先将MySQL5.0安装升级到MySQL5.1，然后再升级到较新的版本。

The mysql_install_db program has been removed from MySQL distributions. mysql_install_db程序已从mysql发行版中删除。Data directory initialization should be performed by invoking mysqld with the --initialize or --initialize-insecure option instead. 数据目录初始化应该通过使用--initialize或--initialize-unsecure选项调用mysqld来执行。In addition, the --bootstrap option for mysqld that was used by mysql_install_db was removed, and the INSTALL_SCRIPTDIR CMake option that controlled the installation location for mysql_install_db was removed.此外，mysql_install_db使用的--bootstrap选项被删除，控制mysql_install_db安装位置的INSTALL_SCRIPTDIRCMake选项也被删除。

The generic partitioning handler was removed from the MySQL server. 通用分区处理程序已从MySQL服务器中删除。In order to support partitioning of a given table, the storage engine used for the table must now provide its own (“native”) partitioning handler. 为了支持给定表的分区，用于该表的存储引擎现在必须提供自己的（“本机”）分区处理程序。The --partition and --skip-partition options are removed from the MySQL Server, and partitioning-related entries are no longer shown in the output of SHOW PLUGINS or in the INFORMATION_SCHEMA.PLUGINS table.从MySQL服务器中删除--partition和--skip-partition选项，与分区相关的条目不再显示在SHOW PLUGINS的输出或INFORMATION_SCHEMA.PLUGINS表中。

Two MySQL storage engines currently provide native partitioning support: InnoDB and NDB. 目前有两个MySQL存储引擎提供本机分区支持：InnoDB和NDB。Of these, only InnoDB is supported in MySQL 8.0. 其中MySQL 8.0只支持InnoDB。Any attempt to create partitioned tables in MySQL 8.0 using any other storage engine fails.在MySQL 8.0中使用任何其他存储引擎创建分区表的任何尝试都将失败。

Ramifications for upgrades.升级的后果。  The direct upgrade of a partitioned table using a storage engine other than InnoDB (such as MyISAM) from MySQL 5.7 (or earlier) to MySQL 8.0 is not supported. 不支持使用InnoDB以外的存储引擎（如MyISAM）将分区表从MySQL5.7（或更早版本）直接升级到MySQL8.0。There are two options for handling such a table:处理此类表有两个选项：

At least one of the two operations just listed must be performed for each partitioned non-InnoDB table prior to upgrading the server to MySQL 8.0. 在将服务器升级到MySQL 8.0之前，必须对每个分区的非InnoDB表执行刚才列出的两个操作中的至少一个。Otherwise, such a table cannot be used following the upgrade.否则，升级后不能使用这样的表。

Due to the fact that table creation statements that would result in a partitioned table using a storage engine without partitioning support now fail with an error (ER_CHECK_NOT_IMPLEMENTED), you must make sure that any statements in a dump file (such as that written by mysqldump) from an older version of MySQL that you wish to import into a MySQL 8.0 server that create partitioned tables do not also specify a storage engine such as MyISAM that has no native partitioning handler. 由于表创建语句会导致使用不支持分区的存储引擎的分区表现在失败并出现错误（ER_CHECK_NOT_IMPLEMENTED），您必须确保转储文件中的任何语句（如mysqldump编写的语句）都不会指定没有本机分区处理程序的存储引擎，例如MyISAM。You can do this by performing either of the following:您可以通过执行以下任一操作来执行此操作：

For more information, see Section 24.6.2, “Partitioning Limitations Relating to Storage Engines”.有关更多信息，请参阅第24.6.2节，“与存储引擎相关的分区限制”。

System and status variable information is no longer maintained in the INFORMATION_SCHEMA. 系统和状态变量信息不再保留在INFORMATION_SCHEMA中。These tables are removed: GLOBAL_VARIABLES, SESSION_VARIABLES, GLOBAL_STATUS, SESSION_STATUS. 这些表已被删除：GLOBAL_VARIABLES、SESSION_VARIABLES、GLOBAL_STATUS、SESSION_STATUS。Use the corresponding Performance Schema tables instead. 改用相应的性能架构表。See Section 27.12.14, “Performance Schema System Variable Tables”, and Section 27.12.15, “Performance Schema Status Variable Tables”. 请参阅第27.12.14节，“性能模式系统变量表”和第27.12.15节，“性能模式状态变量表”。In addition, the show_compatibility_56 system variable was removed. 此外，show_compatibility_56系统变量已删除。It was used in the transition period during which system and status variable information in INFORMATION_SCHEMA tables was moved to Performance Schema tables, and is no longer needed. 它用于过渡时期，在此期间，INFORMATION_SCHEMA<表中的系统和状态变量信息被移动到性能架构表中，不再需要。These status variables are removed: Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running. 这些状态变量被删除：Slave_heartbeat_period、Slave_last_heartbeat、Slave_received_heartbeat、Slave_retried_transactions、Slave_running。The information they provided is available in Performance Schema tables; see Migrating to Performance Schema System and Status Variable Tables.他们提供的信息可以在性能模式表中找到；请参阅迁移到性能模式系统和状态变量表。

The Performance Schema setup_timers table was removed, as was the TICK row in the performance_timers table.性能架构setup_timers表已删除，performance_timers表中的TICK行也已删除。

The libmysqld embedded server library is removed, along with:已删除libmysqld嵌入式服务器库，同时删除：

The mysql_plugin utility was removed. mysql_plugin实用程序已被删除。Alternatives include loading plugins at server startup using the --plugin-load or --plugin-load-add option, or at runtime using the INSTALL PLUGIN statement.替代方法包括在服务器启动时使用-plugin-load或--plugin-load-add选项加载插件，或者在运行时使用INSTALL PLUGIN语句加载插件。

The resolveip utility is removed. 已删除resolveip实用程序。nslookup, host, or dig can be used instead.可以改用nslookup、host或dig。

The resolve_stack_dump utility is removed. 已删除resolve_stack_dump实用程序。Stack traces from official MySQL builds are always symbolized, so there is no need to use resolve_stack_dump.官方MySQL版本的堆栈跟踪总是符号化的，所以不需要使用resolve_Stack_dump。

The following server error codes are not used and have been removed. 以下服务器错误代码未使用，已被删除。Applications that test specifically for any of these errors should be updated.应该更新专门针对这些错误进行测试的应用程序。

ER_BINLOG_READ_EVENT_CHECKSUM_FAILURE
ER_BINLOG_ROW_RBR_TO_SBR
ER_BINLOG_ROW_WRONG_TABLE_DEF
ER_CANT_ACTIVATE_LOG
ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION
ER_CANT_CREATE_FEDERATED_TABLE
ER_CANT_CREATE_SROUTINE
ER_CANT_DELETE_FILE
ER_CANT_GET_WD
ER_CANT_SET_GTID_PURGED_WHEN_GTID_MODE_IS_OFF
ER_CANT_SET_WD
ER_CANT_WRITE_LOCK_LOG_TABLE
ER_CREATE_DB_WITH_READ_LOCK
ER_CYCLIC_REFERENCE
ER_DB_DROP_DELETE
ER_DELAYED_NOT_SUPPORTED
ER_DIFF_GROUPS_PROC
ER_DISK_FULL
ER_DROP_DB_WITH_READ_LOCK
ER_DROP_USER
ER_DUMP_NOT_IMPLEMENTED
ER_ERROR_DURING_CHECKPOINT
ER_ERROR_ON_CLOSE
ER_EVENTS_DB_ERROR
ER_EVENT_CANNOT_DELETE
ER_EVENT_CANT_ALTER
ER_EVENT_COMPILE_ERROR
ER_EVENT_DATA_TOO_LONG
ER_EVENT_DROP_FAILED
ER_EVENT_MODIFY_QUEUE_ERROR
ER_EVENT_NEITHER_M_EXPR_NOR_M_AT
ER_EVENT_OPEN_TABLE_FAILED
ER_EVENT_STORE_FAILED
ER_EXEC_STMT_WITH_OPEN_CURSOR
ER_FAILED_ROUTINE_BREAK_BINLOG
ER_FLUSH_MASTER_BINLOG_CLOSED
ER_FORM_NOT_FOUND
ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF__UNUSED
ER_FRM_UNKNOWN_TYPE
ER_GOT_SIGNAL
ER_GRANT_PLUGIN_USER_EXISTS
ER_GTID_MODE_REQUIRES_BINLOG
ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST
ER_HASHCHK
ER_INDEX_REBUILD
ER_INNODB_NO_FT_USES_PARSER
ER_LIST_OF_FIELDS_ONLY_IN_HASH_ERROR
ER_LOAD_DATA_INVALID_COLUMN_UNUSED
ER_LOGGING_PROHIBIT_CHANGING_OF
ER_MALFORMED_DEFINER
ER_MASTER_KEY_ROTATION_ERROR_BY_SE
ER_NDB_CANT_SWITCH_BINLOG_FORMAT
ER_NEVER_USED
ER_NISAMCHK
ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR
ER_NO_FILE_MAPPING
ER_NO_GROUP_FOR_PROC
ER_NO_RAID_COMPILED
ER_NO_SUCH_KEY_VALUE
ER_NO_SUCH_PARTITION__UNUSED
ER_OBSOLETE_CANNOT_LOAD_FROM_TABLE
ER_OBSOLETE_COL_COUNT_DOESNT_MATCH_CORRUPTED
ER_ORDER_WITH_PROC
ER_PARTITION_SUBPARTITION_ERROR
ER_PARTITION_SUBPART_MIX_ERROR
ER_PART_STATE_ERROR
ER_PASSWD_LENGTH
ER_QUERY_ON_MASTER
ER_RBR_NOT_AVAILABLE
ER_SKIPPING_LOGGED_TRANSACTION
ER_SLAVE_CHANNEL_DELETE
ER_SLAVE_MULTIPLE_CHANNELS_HOST_PORT
ER_SLAVE_MUST_STOP
ER_SLAVE_WAS_NOT_RUNNING
ER_SLAVE_WAS_RUNNING
ER_SP_GOTO_IN_HNDLR
ER_SP_PROC_TABLE_CORRUPT
ER_SQL_MODE_NO_EFFECT
ER_SR_INVALID_CREATION_CTX
ER_TABLE_NEEDS_UPG_PART
ER_TOO_MUCH_AUTO_TIMESTAMP_COLS
ER_UNEXPECTED_EOF
ER_UNION_TABLES_IN_DIFFERENT_DIR
ER_UNSUPPORTED_BY_REPLICATION_THREAD
ER_UNUSED1
ER_UNUSED2
ER_UNUSED3
ER_UNUSED4
ER_UNUSED5
ER_UNUSED6
ER_VIEW_SELECT_DERIVED_UNUSED
ER_WRONG_MAGIC
ER_WSAS_FAILED

The deprecated INFORMATION_SCHEMA INNODB_LOCKS and INNODB_LOCK_WAITS tables are removed. 不推荐使用的INFORMATION_SCHEMA INNODB_LOCKS和INNODB_LOCK_WAITS表被删除。Use the Performance Schema data_locks and data_lock_waits tables instead.改为使用性能架构data_locks和data_lock_waits表。

InnoDB no longer supports compressed temporary tables. InnoDB不再支持压缩的临时表。When innodb_strict_mode is enabled (the default), CREATE TEMPORARY TABLE returns an error if ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE is specified. 当innodb_strict_mode处于启用状态（默认）时，如果指定了ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE，则CREATE TEMPORARY TABLE将返回错误。If innodb_strict_mode is disabled, warnings are issued and the temporary table is created using a non-compressed row format.如果禁用了innodb_strict_mode，将发出警告，并使用非压缩行格式创建临时表。

InnoDB no longer creates .isl files (InnoDB Symbolic Link files) when creating tablespace data files outside of the MySQL data directory. 在MySQL数据目录之外创建表空间数据文件时，InnoDB不再创建.islvs文件（InnoDB符号链接文件）。The innodb_directories option now supports locating tablespace files created outside of the data directory.innodb_directories选项现在支持定位在数据目录之外创建的表空间文件。

With this change, moving a remote tablespace while the server is offline by manually modifying an .isl file is no longer supported. 通过此更改，不再支持在服务器脱机时通过手动修改.isl文件来移动远程表空间。Moving remote tablespace files is now supported by the innodb_directories option. innodb_directories选项现在支持移动远程表空间文件。See Section 15.6.3.6, “Moving Tablespace Files While the Server is Offline”.请参阅第15.6.3.6节，“在服务器脱机时移动表空间文件”。

The following InnoDB file format variables were removed:已删除以下InnoDB文件格式变量：

File format variables were necessary for creating tables compatible with earlier versions of InnoDB in MySQL 5.1. 文件格式变量对于创建与MySQL 5.1中早期版本的InnoDB兼容的表是必需的。Now that MySQL 5.1 has reached the end of its product lifecycle, these options are no longer required.现在MySQL 5.1已经到了其产品生命周期的末尾，不再需要这些选项。

The FILE_FORMAT column was removed from the INNODB_TABLES and INNODB_TABLESPACES Information Schema tables.FILE_FORMAT列已从INNODB_TABLES和INNODB_TABLESPACES信息架构表中删除。

The innodb_support_xa system variable, which enables support for two-phase commit in XA transactions, was removed. innodb_support_xa系统变量已被删除，该变量支持XA事务中的两阶段提交。InnoDB support for two-phase commit in XA transactions is always enabled.始终启用对XA事务中两阶段提交的InnoDB支持。

Support for DTrace was removed.已删除对DTrace的支持。

The JSON_APPEND() function was removed. Use JSON_ARRAY_APPEND() instead.已删除JSON_APPEND()函数。改为使用JSON_ARRAY_APPEND()。

Support for placing table partitions in shared InnoDB tablespaces was removed in MySQL 8.0.13. MySQL 8.0.13中删除了在共享InnoDB表空间中放置表分区的支持。Shared tablespaces include the InnoDB system tablespace and general tablespaces. 共享表空间包括InnoDB系统表空间和通用表空间。For information about identifying partitions in shared tablespaces and moving them to file-per-table tablespaces, see Section 2.11.5, “Preparing Your Installation for Upgrade”.有关标识共享表空间中的分区并将其移动到每个表的文件表空间的信息，请参阅第2.11.5节，“准备升级安装”。

Support for setting user variables in statements other than SET was deprecated in MySQL 8.0.13. MySQL 8.0.13不赞成在非SET语句中设置用户变量。This functionality is subject to removal in MySQL 9.0.此功能可能会在MySQL 9.0中删除。

The --ndb perror option was removed. 已删除--ndb perror选项。Use the ndb_perror utility instead.请改用ndb_perror实用程序。

The innodb_undo_logs variable was removed. innodb_undo_logs变量已删除。The innodb_rollback_segments variables performs the same function and should be used instead.innodb_rollback_segments变量执行相同的功能，应改用。

The Innodb_available_undo_logs status variable was removed. Innodb_available_undo_logs状态变量已删除。The number of available rollback segments per tablespace may be retrieved using SHOW VARIABLES LIKE 'innodb_rollback_segments';每个表空间的可用回滚段数可以使用SHOW VARIABLES LIKE 'innodb_rollback_segments';进行检索；

As of MySQL 8.0.14, the previously deprecated innodb_undo_tablespaces variable is no longer configurable. 从MySQL 8.0.14开始，以前不推荐使用的innodb_undo_tablespaces变量不再是可配置的。For more information, see Section 15.6.3.4, “Undo Tablespaces”.有关更多信息，请参阅第15.6.3.4节，“撤消表空间”。

Support for the ALTER TABLE ... UPGRADE PARTITIONING statement has been removed.对ALTER TABLE ... UPGRADE PARTITIONING语句的支持已被删除。

As of MySQL 8.0.16, support for the internal_tmp_disk_storage_engine system variable has been removed; internal temporary tables on disk now always use the InnoDB storage engine. 从MySQL 8.0.16开始，已删除对internal_tmp_disk_storage_engine系统变量的支持；磁盘上的内部临时表现在总是使用InnoDB存储引擎。See Storage Engine for On-Disk Internal Temporary Tables,for more information.有关更多信息，请参阅磁盘内部临时表的存储引擎。

The DISABLE_SHARED CMake option was unused and has been removed.DISABLE_SHAREDCMake选项未使用，已被删除。