upgrading-from-previous-series.md

### 2.11.4 MySQL 8.0 的变化

在升级到 MySQL 8.0 之前，请查看本节中描述的更改以确定适用于您当前 MySQL 安装和应用程序的更改。执行任何建议的操作。

更改标记为**不兼容的变化**与早期版本的 MySQL 不兼容，可能需要您注意*升级前*.我们的目标是避免这些更改，但有时它们对于纠正比版本之间的不兼容更糟糕的问题是必要的。如果适用于您的安装的升级问题涉及不兼容，请按照说明中的说明进行操作。

-   [数据字典更改](upgrading-from-previous-series.html#upgrade-data-dictionary-changes)

-   [缓存\_沙2\_密码作为首选身份验证插件](upgrading-from-previous-series.html#upgrade-caching-sha2-password)

-   [配置更改](upgrading-from-previous-series.html#upgrade-configuration-changes)

-   [服务器更改](upgrading-from-previous-series.html#upgrade-server-changes)

-   [InnoDB 更改](upgrading-from-previous-series.html#upgrade-innodb-changes)

-   [SQL 更改](upgrading-from-previous-series.html#upgrade-sql-changes)

-   [更改了服务器默认值](upgrading-from-previous-series.html#upgrade-server-defaults)

#### 数据字典更改

MySQL Server 8.0 合并了一个全局数据字典，其中包含有关事务表中数据库对象的信息。在之前的 MySQL 系列中，字典数据存储在元数据文件和非事务系统表中。因此，升级过程要求您通过检查特定先决条件来验证安装的升级准备情况。有关详细信息，请参阅[第 2.11.5 节，“准备升级安装”](upgrade-prerequisites.html).启用数据字典的服务器需要一些一般的操作差异；看[第 14.7 节，“数据字典使用差异”](data-dictionary-usage-differences.html).

#### 缓存\_沙2\_密码作为首选身份验证插件

[](<>)

这`cache_sha2_password`和`sha256_password`身份验证插件提供比`mysql_native_password`插件，和`cache_sha2_password`提供比`sha256_password`.由于这些优越的安全性和性能特点`cache_sha2_password`, 从 MySQL 8.0 开始，它是首选的身份验证插件，也是默认的身份验证插件，而不是`mysql_native_password`.此更改同时影响服务器和`libmysql客户端`客户端库：

-   对于服务器，默认值[`default_authentication_plugin`](server-system-variables.html#sysvar_default_authentication_plugin)系统变量从`mysql_native_password`到`cache_sha2_password`.

    此更改仅适用于安装或升级到 MySQL 8.0 或更高版本后创建的新帐户。对于升级安装中已经存在的帐户，其身份验证插件保持不变。希望切换到的现有用户`cache_sha2_password`可以使用[`更改用户`](alter-user.html)陈述：

    ```
    ALTER USER user
      IDENTIFIED WITH caching_sha2_password
      BY 'password';
    ```

-   这`libmysql客户端`图书馆款待`cache_sha2_password`作为默认的身份验证插件，而不是`mysql_native_password`.

    以下各节讨论了更突出的作用的含义`cache_sha2_password`：

-   [缓存\_沙2\_密码兼容性问题和解决方案](upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues)

-   [缓存\_沙2\_密码兼容的客户端和连接器](upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatible-connectors)

-   [缓存\_沙2\_密码和根管理帐户](upgrading-from-previous-series.html#upgrade-caching-sha2-password-root-account)

-   [缓存\_沙2\_密码和复制](upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication)

##### 缓存\_沙2\_密码兼容性问题和解决方案

重要的

如果您的 MySQL 安装必须为 8.0 之前的客户端提供服务，并且在升级到 MySQL 8.0 或更高版本后遇到兼容性问题，解决这些问题并恢复 8.0 之前兼容性的最简单方法是重新配置服务器以恢复到以前的默认身份验证插件 (`mysql_native_password`）。例如，在服务器选项文件中使用这些行：

```
[mysqld]
default_authentication_plugin=mysql_native_password
```

该设置使 8.0 之前的客户端能够连接到 8.0 服务器，直到升级安装中使用的客户端和连接器以了解`cache_sha2_password`.但是，该设置应被视为暂时的，而不是长期或永久的解决方案，因为它会导致使用该设置创建的新帐户放弃由该设置提供的改进的身份验证安全性`cache_sha2_password`.

指某东西的用途`cache_sha2_password`提供比密码散列更安全的密码`mysql_native_password`（以及随之而来的改进的客户端连接身份验证）。然而，它也有可能影响现有 MySQL 安装的兼容性问题：

-   尚未更新了解的客户端和连接器`cache_sha2_password`连接到配置有的 MySQL 8.0 服务器可能会遇到问题`cache_sha2_password`作为默认的身份验证插件，即使使用未通过身份验证的帐户`cache_sha2_password`.出现此问题是因为服务器将其默认身份验证插件的名称指定给客户端。如果客户端或连接器基于不能正常处理无法识别的默认身份验证插件的客户端/服务器协议实现，则它可能会失败并出现以下错误之一：

    [](<>)[](<>)[](<>)

    ```
    Authentication plugin 'caching_sha2_password' is not supported
    ```

    ```
    Authentication plugin 'caching_sha2_password' cannot be loaded:
    dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password.so, 2):
    image not found
    ```

    ```
    Warning: mysqli_connect(): The server requested authentication
    method unknown to the client [caching_sha2_password]
    ```

    有关编写连接器以优雅地处理来自服务器的未知默认身份验证插件请求的信息，请参阅[身份验证插件连接器 - 编写注意事项](pluggable-authentication.html#pluggable-authentication-connector-writing).

-   使用通过身份验证的帐户的客户端`cache_sha2_password`必须使用安全连接（使用 TCP 使用 TLS/SSL 凭证、Unix 套接字文件或共享内存），或使用 RSA 密钥对支持密码交换的未加密连接。此安全要求不适用于`mysql_native_passsword`，所以切换到`cache_sha2_password`可能需要额外的配置（见[第 6.4.1.2 节，“缓存 SHA-2 可插入身份验证”](caching-sha2-pluggable-authentication.html)）。但是，默认情况下 MySQL 8.0 中的客户端连接更喜欢使用 TLS/SSL，因此已经符合该偏好的客户端可能不需要额外的配置。

-   尚未更新了解的客户端和连接器`cache_sha2_password` *不能*连接到通过身份验证的帐户`cache_sha2_password`因为他们不认为这个插件是有效的。（这是如何应用客户端/服务器身份验证插件兼容性要求的特定实例，如在[身份验证插件客户端/服务器兼容性](pluggable-authentication.html#pluggable-authentication-compatibility).) 要解决此问题，请重新链接客户端`libmysql客户端`从 MySQL 8.0 或更高版本，或获取更新的连接器，该连接器可识别`cache_sha2_password`.

-   因为`cache_sha2_password`现在也是默认的身份验证插件`libmysql客户端`客户端库，身份验证需要客户端/服务器协议中的额外往返行程，以便从 MySQL 8.0 客户端连接到使用`mysql_native_password`（以前的默认身份验证插件），除非客户端程序被调用[`--default-auth=mysql_native_password`](connection-options.html#option_general_default-auth)选项。

    这`libmysql客户端`8.0 之前 MySQL 版本的客户端库能够连接到 MySQL 8.0 服务器（除了通过以下方式进行身份验证的帐户）`cache_sha2_password`）。这意味着 8.0 之前的客户端基于`libmysql客户端`应该也能连接。例子：

-   标准 MySQL 客户端，例如[**mysql**](mysql.html)和[**mysql管理员**](mysqladmin.html)是`libmysql客户端`-基于。

-   Perl DBI 的 DBD::mysql 驱动程序是`libmysql客户端`-基于。

-   MySQL 连接器/Python 有一个 C 扩展模块，它是`libmysql客户端`-基于。要使用它，请包括`use_pure=False`连接时的选项。

    当现有的 MySQL 8.0 安装升级到 MySQL 8.0.4 或更高版本时，一些较旧的`libmysql客户端`如果它们是动态链接的，则基于 -based 的客户端可能会“自动”升级，因为它们使用升级安装的新客户端库。例如，如果 Perl DBI 的 DBD::mysql 驱动程序使用动态链接，它可以使用`libmysql客户端`在升级到 MySQL 8.0.4 或更高版本后就位，结果如下：

-   在升级之前，使用 DBD::mysql 的 DBI 脚本可以连接到 MySQL 8.0 服务器，但通过以下方式进行身份验证的帐户除外`cache_sha2_password`.

-   升级后，同样的脚本就可以使用了`cache_sha2_password`帐户也是如此。

    然而，出现上述结果是因为`libmysqlclient`8.0.4之前的MySQL 8.0安装中的实例是二进制兼容的：它们都使用共享库主版本号21。适用于链接到`libmysqlclient`从MySQL 5.7或更早版本开始，它们链接到一个共享库，该库的版本号不同，不兼容二进制文件。在这种情况下，必须对客户端进行重新编译`libmysqlclient`从8.0.4或更高版本开始，与MySQL 8.0服务器和`缓存_sha2_密码`账户

    MySQL Connector/J 5.1到8.0.8能够连接到MySQL 8.0服务器，但通过`缓存_sha2_密码`（需要连接连接器/J 8.0.9或更高版本`缓存_sha2_密码`账户。）

    使用客户机/服务器协议实现而不是`libmysqlclient`可能需要升级到理解新身份验证插件的新版本。例如，在PHP中，MySQL连接通常基于`mysqlnd`，目前尚不清楚`缓存_sha2_密码`.直到更新版本的`mysqlnd`如果可用，使PHP客户端能够连接到MySQL 8.0的方法是重新配置服务器以恢复到MySQL 8.0`mysql_本机_密码`作为默认的身份验证插件，如前所述。

    如果客户机或连接器支持显式指定默认身份验证插件的选项，请使用它来命名插件，而不是`缓存_sha2_密码`.例如：

-   一些MySQL客户端支持[`--默认身份验证`](connection-options.html#option_general_default-auth)选项（标准MySQL客户端，例如[**mysql**](mysql.html)和[**mysqladmin**](mysqladmin.html)支持此选项，但可以在没有此选项的情况下成功连接到8.0服务器。然而，其他客户可能支持类似的选择。如果是的话，值得一试。）

-   使用`libmysqlclient`C API可以调用[`mysql_选项（）`](https://dev.mysql.com/doc/c-api/8.0/en/mysql-options.html)与`MYSQL\u默认值\u身份验证`选项

-   使用客户机/服务器协议的本机Python实现的MySQL连接器/Python脚本可以指定`auth_插件`连接选项。（或者，使用Connector/Python C扩展，它能够连接到MySQL 8.0服务器，而不需要`auth_插件`.)

##### 缓存\_沙2\_密码兼容的客户端和连接器

如果客户机或连接器可用且已更新以了解`缓存_sha2_密码`，当连接到配置了的MySQL 8.0服务器时，使用它是确保兼容性的最佳方式`缓存_sha2_密码`作为默认的身份验证插件。

这些客户端和连接器已升级为支持`缓存_sha2_密码`:

-   这个`libmysqlclient`MySQL 8.0（8.0.4或更高版本）中的客户端库。标准MySQL客户端，例如[**mysql**](mysql.html)和[**mysqladmin**](mysqladmin.html)是`libmysqlclient`-基于，所以它们也是兼容的。

-   这个`libmysqlclient`MySQL 5.7（5.7.23或更高版本）中的客户端库。标准MySQL客户端，例如[**mysql**](mysql.html)和[**mysqladmin**](mysqladmin.html)是`libmysqlclient`-基于，所以它们也是兼容的。

-   MySQL Connector/C++1.1.11或更高版本或8.0.7或更高版本。

-   MySQL连接器/J 8.0.9或更高版本。

-   MySQL Connector/NET 8.0.10或更高版本（通过经典的MySQL协议）。

-   MySQL连接器/节点。js 8.0.9或更高版本。

-   PHP:X DevAPI PHP扩展（mysql）\_xdevapi）支持`缓存_sha2_密码`.

    PHP:PDO_MySQL和ext/mysqli扩展不支持`缓存_sha2_密码`。此外，当与7.1.16之前的PHP版本和7.2.4之前的PHP 7.2版本一起使用时，它们无法与`默认认证插件=缓存密码`即使`缓存_sha2_密码`没有使用。

##### 缓存\_沙2\_密码和根管理帐户

对于升级到MySQL 8.0，现有帐户的身份验证插件保持不变，包括`“根”@“本地主机”`行政账户。

对于新的MySQL 8.0安装，当您初始化数据目录时（使用[第2.10.1节，“初始化数据目录”](data-directory-initialization.html))，这个`“根”@“本地主机”`帐户被创建，并且该帐户使用`缓存_sha2_密码`默认情况下。因此，要在数据目录初始化后连接到服务器，必须使用支持`缓存_sha2_密码`.如果你能做到但更喜欢`根`帐户使用`mysql_本机_密码`安装完成后，安装MySQL并像往常一样初始化数据目录。然后连接到服务器作为`根`使用[`改变用户`](alter-user.html)更改帐户身份验证插件和密码的步骤如下：

```
ALTER USER 'root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'password';
```

如果您使用的客户端或连接器尚不支持`缓存_sha2_密码`，可以使用修改后的数据目录初始化过程将`根`交代`mysql_本机_密码`账户一创建就可以。为此，请使用以下任一技术：

-   提供[`--默认身份验证插件=mysql\u本机\u密码`](server-system-variables.html#sysvar_default_authentication_plugin)随附选项[`--初始化`](server-options.html#option_mysqld_initialize)或[`--初始化不安全`](server-options.html#option_mysqld_initialize-insecure).

-   设置[`默认认证插件`](server-system-variables.html#sysvar_default_authentication_plugin)到`mysql_本机_密码`在选项文件中，并使用[`--默认文件`](server-options.html#option_mysqld_defaults-file)随附选项[`--初始化`](server-options.html#option_mysqld_initialize)或[`--初始化不安全`](server-options.html#option_mysqld_initialize-insecure)（在这种情况下，如果您继续在后续服务器启动中使用该选项文件，将使用创建新帐户。）`mysql_本机_密码`而不是`缓存_sha2_密码`除非你移除[`默认认证插件`](server-system-variables.html#sysvar_default_authentication_plugin)从选项文件中进行设置。）

##### 缓存\_沙2\_密码和复制

在所有服务器都已升级到MySQL 8.0.4或更高版本的复制场景中，到源服务器的副本连接可以使用通过`缓存_sha2_密码`。对于此类连接，同样的要求适用于使用通过身份验证的帐户的其他客户端`缓存_sha2_密码`：使用安全连接或基于RSA的密码交换。

连接到`缓存_sha2_密码`源/副本复制的帐户：

-   使用以下任何一项[`将主机更改为`](change-master-to.html)选项：

    ```
    MASTER_SSL = 1
    GET_MASTER_PUBLIC_KEY = 1
    MASTER_PUBLIC_KEY_PATH='path to RSA public key file'
    ```

-   或者，如果在服务器启动时提供了所需的密钥，则可以使用RSA公钥相关选项。

    连接到`缓存_sha2_密码`组复制的帐户：

-   对于使用OpenSSL构建的MySQL，请设置以下任何系统变量：

    ```
    SET GLOBAL group_replication_recovery_use_ssl = ON;
    SET GLOBAL group_replication_recovery_get_public_key = 1;
    SET GLOBAL group_replication_recovery_public_key_path = 'path to RSA public key file';
    ```

-   或者，如果在服务器启动时提供了所需的密钥，则可以使用RSA公钥相关选项。

#### 配置更改

-   **不相容的变化**：MySQL存储引擎现在负责提供自己的分区处理程序，MySQL服务器不再提供通用分区支持。[`InnoDB`](innodb-storage-engine.html)和`NDB`是唯一提供MySQL 8.0支持的本机分区处理程序的存储引擎。必须对使用任何其他存储引擎的分区表进行更改，以将其转换为`InnoDB`或`NDB`，或删除其分区-*之前*升级服务器，否则以后无法使用。

    有关转换的信息`米萨姆`桌子`InnoDB`看见[第15.6.1.5节，“将表格从MyISAM转换为InnoDB”](converting-tables-to-innodb.html).

    如果表创建语句使用存储引擎生成分区表，而不提供此类支持，则会出现错误（ER）\_检查\_不\_在MySQL 8.0中实现。如果使用以下命令从MySQL 5.7（或更早版本）中创建的转储文件导入数据库：[**mysqldump**](mysqldump.html)在MySQL 8.0服务器中，必须确保创建分区表的任何语句也不会指定不受支持的存储引擎，方法是删除对分区的任何引用，或将存储引擎指定为`InnoDB`或者将其设置为`InnoDB`默认情况下。

    笔记

    程序见[第2.11.5节，“为升级准备安装”](upgrade-prerequisites.html)，描述如何识别升级到MySQL 8.0之前必须更改的分区表。

    看见[第24.6.2节，“与存储引擎相关的分区限制”](partitioning-limitations-storage-engines.html)，以获取更多信息。

-   **不相容的变化**：多个服务器错误代码未使用且已被删除（有关列表，请参阅[MySQL 8.0中删除的功能](mysql-nutshell.html#mysql-nutshell-removals))。应更新专门针对其中任何一个进行测试的应用程序。

-   **重要变化**：默认字符集已从`拉丁语1`到`utf8mb4`.这些系统变量受到影响：

    -   的默认值[`字符集服务器`](server-system-variables.html#sysvar_character_set_server)和[`字符集数据库`](server-system-variables.html#sysvar_character_set_database)系统变量已从`拉丁语1`到`utf8mb4`.

    -   的默认值[`整理服务器`](server-system-variables.html#sysvar_collation_server)和[`整理数据库`](server-system-variables.html#sysvar_collation_database)系统变量已从`拉丁语瑞典语`到`utf8mb4_0900_ai_ci`.

        因此，新对象的默认字符集和排序规则与以前不同，除非指定了显式字符集和排序规则。这包括数据库和其中的对象，例如表、视图和存储程序。假设使用了以前的默认值，保存它们的一种方法是在`我的cnf`文件：

    ```
    [mysqld]
    character_set_server=latin1
    collation_server=latin1_swedish_ci
    ```

    在复制设置中，当从MySQL 5.7升级到8.0时，建议在升级之前将默认字符集更改回MySQL 5.7中使用的字符集。升级完成后，可以将默认字符集更改为`utf8mb4`.

-   **不相容的变化**：从MySQL 8.0.11开始，禁止使用[`小写字母表名称`](server-system-variables.html#sysvar_lower_case_table_names)与服务器初始化时使用的设置不同的设置。这种限制是必要的，因为各种数据字典表字段使用的排序规则都基于[`小写字母表名称`](server-system-variables.html#sysvar_lower_case_table_names)初始化服务器时定义的设置，以及使用不同的设置重新启动服务器会导致标识符排序和比较方式不一致。

#### 服务器更改

-   在MySQL 8.0.11中，与帐户管理相关的几个不推荐的功能被删除，例如[`授予`](grant.html)语句来修改用户帐户的非特权特征`无自动创建用户`SQL模式`密码（）`功能，以及`旧密码`系统变量。

    从MySQL 5.7到8.0复制引用这些已删除功能的语句可能会导致复制失败。应修改使用任何已删除功能的应用程序，以避免使用这些功能，并在可能的情况下使用替代功能，如中所述[MySQL 8.0中删除的功能](mysql-nutshell.html#mysql-nutshell-removals).

    为了避免MySQL 8.0上的启动失败，请删除`无自动创建用户`从…起[`sql_模式`](server-system-variables.html#sysvar_sql_mode)MySQL选项文件中的系统变量设置。

    加载包含`无自动创建用户`MySQL 8.0服务器中存储程序定义中的SQL模式会导致故障。从MySQL 5.7.24和MySQL 8.0.13开始，[**mysqldump**](mysqldump.html)移除`无自动创建用户`来自存储程序定义。转储使用早期版本的`mysqldump`必须手动修改才能删除的实例`无自动创建用户`.

-   在MySQL 8.0.11中，删除了这些不推荐的兼容SQL模式：`DB2`, `MAXDB`, `MSSQL`, `MYSQL323`, `MYSQL40`, `神谕`, `POSTGRESQL`, `无字段选项`, `没有按键选项`, `没有表格选项`.他们不能再被分配到`sql_模式`系统变量或用作[**mysqldump**](mysqldump.html) [`--兼容的`](mysqldump.html#option_mysqldump_compatible)选项

    移除`MAXDB`意味着`时间戳`的数据类型[`创建表格`](create-table.html)或[`改变桌子`](alter-table.html)不再被视为[`约会时间`](datetime.html).

    从MySQL 5.7到8.0复制引用已删除SQL模式的语句可能会导致复制失败。这包括复制`创造`存储程序（存储过程和函数、触发器和事件）的语句，这些语句在当前[`sql_模式`](server-system-variables.html#sysvar_sql_mode)值包括任何已删除的模式。应修改使用任何已删除模式的应用程序，以避免它们。

-   从MySQL 8.0.3开始，空间数据类型允许`SRID`属性，以明确指示存储在列中的值的空间参考系（SRS）。看见[第11.4.1节，“空间数据类型”](spatial-type-overview.html).

    带有显式`SRID`属性受SRID限制：列只接受具有该ID的值，并且`空间的`列上的索引将由优化器使用。优化器忽略了`空间的`空间列上没有索引的索引`SRID`属性看见[第8.3.3节，“空间索引优化”](spatial-index-optimization.html)如果希望优化器考虑`空间的`不受SRID限制的空间列上的索引，应修改每个此类列：

    -   验证列中的所有值是否具有相同的SRID。确定几何图形列中包含的SRID的步骤*`上校的名字`*，使用以下查询：

        ```
        SELECT DISTINCT ST_SRID(col_name) FROM tbl_name;
        ```

        如果查询返回多行，则该列将混合使用SRID。在这种情况下，请修改其内容，使所有值具有相同的SRID。

    -   重新定义列以具有显式`SRID`属性

    -   重现`空间的`指数

-   MySQL 8.0.0中删除了几个空间函数，原因是空间函数名称空间的更改实现了`圣_`执行精确操作的函数的前缀，或`膜生物反应器`基于最小边界矩形执行操作的函数的前缀。在生成的列定义中使用删除的空间函数可能会导致升级失败。升级之前，请运行[**mysqlcheck——检查升级**](mysqlcheck.html)用于删除的空间函数，并用其`圣_`或`膜生物反应器`指定替代者。有关删除的空间函数的列表，请参阅[MySQL 8.0中删除的功能](mysql-nutshell.html#mysql-nutshell-removals).

-   这个[`备份管理`](privileges-provided.html#priv_backup-admin)权限将自动授予具有[`重新加载`](privileges-provided.html#priv_reload)执行MySQL 8.0.3或更高版本的就地升级时的权限。

-   从MySQL 8.0.13开始，由于基于行或混合的复制模式与基于语句的复制模式在处理临时表的方式上存在差异，因此在运行时切换二进制日志格式有了新的限制。

    -   `设置@会话。binlog_格式`如果会话有任何打开的临时表，则无法使用。

    -   `设置@@global。binlog_格式`和`设置@persist。binlog_格式`如果任何复制通道有任何打开的临时表，则无法使用。`仅设置@@persist\u。binlog_格式`如果复制通道具有打开的临时表，则允许，因为`坚持`, `只有你`不修改运行时全局系统变量值。

    -   `设置@@global。binlog_格式`和`设置@persist。binlog_格式`如果任何复制通道应用程序正在运行，则无法使用。这是因为更改仅在复制通道的应用程序重新启动时生效，此时复制通道可能有打开的临时表。这种行为比以前更加严格。`仅设置@@persist\u。binlog_格式`如果任何复制通道应用程序正在运行，则允许。

    -   在MySQL 8.0.27中，为[`内部存储引擎`](server-system-variables.html#sysvar_internal_tmp_mem_storage_engine)需要[`会话变量管理`](privileges-provided.html#priv_session-variables-admin)或[`系统变量管理`](privileges-provided.html#priv_system-variables-admin)特权

    -   从MySQL 8.0.27开始，克隆插件允许在执行克隆操作的同时，在捐赠方MySQL服务器实例上同时执行DDL操作。以前，克隆操作期间保留了一个备份锁，防止了供体上的并发DDL。要恢复到以前在克隆操作期间阻止供体上并发DDL的行为，请启用[`克隆块ddl`](clone-plugin-options-variables.html#sysvar_clone_block_ddl)变量看见[第5.6.7.4节，“克隆和并发DDL”](clone-plugin-concurrent-ddl.html).

#### InnoDB的变化

-   [`信息模式`](information-schema.html)基于`InnoDB`系统表被数据字典表上的内部系统视图替换。影响`InnoDB` [`信息模式`](information-schema.html)视图被重命名为：

    [](<>)

    **表2.16重命名的InnoDB信息模式视图**

    | 老名字 | 新名字 |
    | --- | --- |
    | `INNODB_系统_列` | `INNODB_列` |
    | `INNODB_系统_数据文件` | `INNODB_数据文件` |
    | `INNODB_系统_字段` | `INNODB_字段` |
    | `INNODB_SYS_FOREIGN` | `INNODB_FOREIGN` |
    | `INNODB_SYS_FOREIGN_COLS` | `INNODB_FOREIGN_COLS` |
    | `INNODB_系统索引` | `INNODB_索引` |
    | `INNODB_系统_表` | `INNODB_表` |
    | `INNODB_SYS_表空间` | `INNODB_表空间` |
    | `INNODB_系统_表状态` | `INNODB_表状态` |
    | `INNODB_系统_虚拟` | `INNODB_虚拟` |

    升级到MySQL 8.0.3或更高版本后，更新引用以前版本的所有脚本`InnoDB` [`信息模式`](information-schema.html)查看名称。

-   这个[zlib图书馆](http://www.zlib.net/)与MySQL捆绑的版本从版本1.2.3提升到版本1.2.11。

    zlib`压缩绑定（）`zlib 1.2.11中的函数返回的缓冲区大小估计值比zlib 1.2.3版中的值略高，这是压缩给定字节长度所需的。这个`压缩绑定（）`函数由调用`InnoDB`函数，用于确定创建压缩文件时允许的最大行大小`InnoDB`表或在压缩文件中插入和更新行`InnoDB`桌子。因此[`创建表格。。。行_格式=压缩`](create-table.html), [`插入`](insert.html)和[`使现代化`](update.html)在早期版本中，行大小非常接近最大行大小的操作可能会失败。要避免此问题，请测试[`创建表格`](create-table.html)压缩语句`InnoDB`升级之前，MySQL 8.0测试实例上有大行的表。

-   随着[`--innodb目录`](innodb-parameters.html#sysvar_innodb_directories)功能，每个表的文件位置和使用绝对路径或在数据目录之外的位置创建的常规表空间文件应添加到[`innodb_目录`](innodb-parameters.html#sysvar_innodb_directories)参数值。否则`InnoDB`在恢复期间无法找到这些文件。要查看表空间文件位置，请查询[`信息模式。文件夹`](information-schema-files-table.html)表：

    ```
    SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G
    ```

-   撤消日志不能再驻留在系统表空间中。在MySQL 8.0中，默认情况下，撤销日志驻留在两个撤销表空间中。有关更多信息，请参阅[第15.6.3.4节，“撤消表空间”](innodb-undo-tablespaces.html).

    从MySQL 5.7升级到MySQL 8.0时，MySQL 5.7实例中存在的所有undo表空间都将被删除，并替换为两个新的默认undo表空间。默认的撤消表空间是在[`innodb_undo_目录`](innodb-parameters.html#sysvar_innodb_undo_directory)变量如果[`innodb_undo_目录`](innodb-parameters.html#sysvar_innodb_undo_directory)变量未定义，则在数据目录中创建撤消表空间。从MySQL 5.7升级到MySQL 8.0需要缓慢关闭，以确保MySQL 5.7实例中的undo表空间为空，从而允许安全地删除它们。

    当从早期的MySQL 8.0版本升级到MySQL 8.0.14或更高版本时，由于[`innodb_undo_表空间`](innodb-parameters.html#sysvar_innodb_undo_tablespaces)大于2的设置被视为用户定义的撤消表空间，可以使用[`改变撤销表空间`](alter-tablespace.html)和[`删除撤消表空间`](drop-tablespace.html)语法，分别在升级后。MySQL 8.0发行版系列中的升级可能并不总是需要缓慢关闭，这意味着现有的undo表空间可能包含undo日志。因此，升级过程不会删除现有的撤消表空间。

-   **不相容的变化**：从MySQL 8.0.17开始[`创建表空间。。。添加数据文件`](create-tablespace.html)子句不允许循环目录引用。例如，循环目录引用(`/../`)不允许在以下声明中使用：

    ```
    CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';
    ```

    Linux上存在一个例外，如果前面的目录是符号链接，则允许循环目录引用。例如，如果*`有目录吗`*是一种象征性的联系。（仍然允许数据文件路径以'`../`'.)

    为了避免升级问题，请在升级到MySQL 8.0.17或更高版本之前，从表空间数据文件路径中删除所有循环目录引用。要检查表空间路径，请查询[`信息模式。INNODB_数据文件`](information-schema-innodb-datafiles-table.html)桌子

-   由于MySQL 8.0.14中引入了一种回归，对于具有分区表和数据库的实例，从MySQL 5.7或MySQL 8.0.14之前的MySQL 8.0版本到MySQL 8.0.16的区分大小写文件系统的就地升级失败[`小写字母表名称=1`](server-system-variables.html#sysvar_lower_case_table_names)。失败是由与分区表文件名相关的大小写不匹配问题引起的。引入回归的修复被恢复，允许从MySQL 5.7或MySQL 8.0.14之前的MySQL 8.0版本升级到MySQL 8.0.17，以正常运行。然而，MySQL 8.0.14、8.0.15和8.0.16版本中仍然存在这种回归。

    在将二进制文件或包升级到MySQL 8.0.17后，如果存在分区表且[`小写字母表名称=1`](server-system-variables.html#sysvar_lower_case_table_names):

    ```
    Upgrading from server version version_number with
    partitioned tables and lower_case_table_names == 1 on a case sensitive file
    system may cause issues, and is therefore prohibited. To upgrade anyway, restart
    the new server version with the command line option 'upgrade=FORCE'. When
    upgrade is completed, please execute 'RENAME TABLE part_table_name
    TO new_table_name; RENAME TABLE new_table_name
    TO part_table_name;' for each of the partitioned tables.
    Please see the documentation for further information.
    ```

    如果在升级到MySQL 8.0.17时遇到此错误，请执行以下解决方法：

    1.  使用以下命令重新启动服务器：[`--升级=强制`](server-options.html#option_mysqld_upgrade)以强制升级操作继续。

    2.  用小写分区名称分隔符标识分区表文件名`（#p#`或`#sp#`):

        ```
        mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
        ```

    3.  对于标识的每个文件，使用临时名称重命名关联的表，然后将表重命名回其原始名称。

        ```
        mysql> RENAME TABLE table_name TO temporary_table_name;
        mysql> RENAME TABLE temporary_table_name TO table_name;
        ```

    4.  验证没有分区表文件名小写分区名分隔符（应返回空结果集）。

        ```
        mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
        Empty set (0.00 sec)
        ```

    5.  跑[`分析表`](analyze-table.html)在每个重命名的表上更新`mysql。innodb_索引_统计数据`和`mysql。innodb_表_统计数据`桌子。

        由于MySQL 8.0.14、8.0.15和8.0.16版本中仍然存在回归，在区分大小写的文件系统上不支持将分区表从MySQL 8.0.14、8.0.15或8.0.16导入MySQL 8.0.17[`小写字母表名称=1`](server-system-variables.html#sysvar_lower_case_table_names)。尝试这样做会导致“表空间对于表丢失”错误。

-   MySQL在为表分区构造表空间名称和文件名时使用分隔符字符串。A“`#p#`分隔符字符串位于分区名称之前，并且`#sp#`“分隔符字符串位于子分区名称之前，如图所示：

    ```
          schema_name.table_name#p#partition_name#sp#subpartition_name
          table_name#p#partition_name#sp#subpartition_name.ibd
    ```

    过去，分隔符字符串一直是大写的(`#P#`和`#SP#`)在Linux和小写等区分大小写的文件系统上(`#p#`和`#sp#`)在不区分大小写的文件系统上，如Windows。从MySQL 8.0.19开始，所有文件系统上的分隔符字符串都是小写的。此更改可防止在区分大小写和不区分大小写的文件系统之间迁移数据目录时出现问题。不再使用大写分隔符字符串。

    此外，基于用户指定的分区或子分区名称生成的分区表空间名称和文件名（可以以大写或小写形式指定）现在以小写形式生成（并在内部存储），而不管[`lower_case_table_names`](server-system-variables.html#sysvar_lower_case_table_names)设置以确保不区分大小写。例如，如果使用名称创建表分区`第1部分`，生成的表空间名和文件名都是小写的：

    ```
          schema_name.table_name#p#part_1
          table_name#p#part_1.ibd
    ```

    在升级期间，MySQL 会检查并在必要时进行修改：

    -   磁盘上和数据字典中的分区文件名，以确保小写分隔符和分区名称。

    -   数据字典中的分区元数据，用于先前错误修复引入的相关问题。

    -   `InnoDB`先前错误修复引入的相关问题的统计数据。

        在表空间导入操作期间，会检查磁盘上的分区表空间文件名，并在必要时进行修改，以确保小写分隔符和分区名称。

-   从 MySQL 8.0.21 开始，如果发现表空间数据文件位于未知目录中，则会在启动时或从 MySQL 5.7 升级时将警告写入错误日志。已知目录是由[`数据目录`](server-system-variables.html#sysvar_datadir),[`innodb_data_home_dir`](innodb-parameters.html#sysvar_innodb_data_home_dir)， 和[`innodb_directories`](innodb-parameters.html#sysvar_innodb_directories)变量。要使目录为人所知，请将其添加到[`innodb_directories`](innodb-parameters.html#sysvar_innodb_directories)环境。使目录已知可确保在恢复期间可以找到数据文件。有关详细信息，请参阅[崩溃恢复期间的表空间发现](innodb-recovery.html#innodb-recovery-tablespace-discovery).

#### SQL 更改

-   **不兼容的变化**：从 MySQL 8.0.13 开始，已弃用`ASC`要么`DESC`限定词`通过...分组`条款已被删除。以前依赖的查询`通过...分组`排序可能会产生与以前的 MySQL 版本不同的结果。要生成给定的排序顺序，请提供`订购方式`条款。

    使用 MySQL 8.0.12 或更低版本的查询和存储的程序定义`ASC`要么`DESC`限定词`通过...分组`应修改条款。否则，升级到 MySQL 8.0.13 或更高版本可能会失败，就像复制到 MySQL 8.0.13 或更高版本的副本服务器一样。

-   某些关键字可能在 MySQL 8.0 中保留，而在 MySQL 5.7 中未保留。看[第 9.3 节，“关键字和保留字”](keywords.html).这可能导致以前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引用。看[第 9.2 节，“架构对象名称”](identifiers.html).

-   升级后，建议您测试应用程序代码中指定的优化器提示，以确保仍然需要这些提示来实现所需的优化策略。优化器增强有时会使某些优化器提示变得不必要。在某些情况下，不必要的优化器提示甚至可能适得其反。

-   **不兼容的变化**：在 MySQL 5.7 中，指定一个`外键`的定义`InnoDB`没有表的`约束 *`象征`*`子句，或指定`约束`没有关键字的`象征`, 原因`InnoDB`使用生成的约束名称。这种行为在 MySQL 8.0 中发生了变化，`InnoDB`使用`外键 *`索引名称`*`值而不是生成的名称。由于每个模式（数据库）的约束名称必须是唯一的，因此由于外键索引名称在每个模式中不是唯一的，因此更改会导致错误。为避免此类错误，新的约束命名行为已在 MySQL 8.0.16 中恢复，并且`InnoDB`再次使用生成的约束名称。

    为了与`InnoDB`,`新开发银行`基于 MySQL 8.0.16 或更高版本的版本使用生成的约束名称，如果`约束 *`象征`*`子句未指定，或`约束`没有指定关键字`象征`.`新开发银行`基于 MySQL 5.7 的版本和更早的 MySQL 8.0 版本使用`外键 *`索引名称`*`价值。

    上述更改可能会导致依赖于先前外键约束命名行为的应用程序不兼容。

-   MySQL流控函数对系统变量值的处理，例如[`IFNULL()`](flow-control-functions.html#function_ifnull)和[`案子（）`](flow-control-functions.html#operator_case)在 MySQL 8.0.22 中更改；系统变量值现在被处理为相同字符和排序规则的列值，而不是常量。使用这些函数和以前成功的系统变量的一些查询随后可能会因非法混合排序规则而被拒绝。在这种情况下，将系统变量转换为正确的字符集和排序规则。

-   **不兼容的变化**：MySQL 8.0.28 修复了以前的 MySQL 8.0 版本中的一个问题，即[`转变（）`](cast-functions.html#function_convert)函数有时允许无效转换[`二进制`](binary-varbinary.html)非二进制字符集的值。应检查可能依赖此行为的应用程序，并在必要时在升级前进行修改。

    特别是，在`转变（）`被用作索引生成列的表达式的一部分，函数行为的更改可能会导致升级到 MySQL 8.0.28 后索引损坏。您可以按照以下步骤防止这种情况发生：

    1.  在执行升级之前，更正任何无效的输入数据。

    2.  删除然后重新创建索引。

        您还可以使用强制重建表[`更改表 *`桌子`* 力量`](alter-table.html)， 反而。

    3.  升级 MySQL 软件。

        如果您无法事先验证输入数据，则在升级到 MySQL 8.0.28 之前，您不应重新创建索引或重建表。

#### 更改了服务器默认值

MySQL 8.0 带有改进的默认值，旨在尽可能提供最佳的开箱即用体验。这些变化是由技术进步（机器拥有更多 CPU、使用 SSD 等）、存储更多数据、MySQL 不断发展（InnoDB、Group Replication、AdminAPI）等事实驱动的。下表总结了为大多数用户提供最佳 MySQL 体验而更改的默认值。

| 选项/参数 | 旧默认 | 新默认值 |
| ----- | --- | ---- |
| *服务器更改* |  |  |
| [`character_set_server`](server-system-variables.html#sysvar_character_set_server) | 拉丁语1 | utf8mb4 |
| [`collat​​ion_server`](server-system-variables.html#sysvar_collation_server) | 拉丁语1\_瑞典\_词 | utf8mb4_0900\_艾\_词 |
| [`显式默认值for_timestamp`](server-system-variables.html#sysvar_explicit_defaults_for_timestamp) | 离开 | 在 |
| [`optimizer_trace_max_mem_size`](server-system-variables.html#sysvar_optimizer_trace_max_mem_size) | 16KB | 1MB |
| [`validate_password_check_user_name`](validate-password-options-variables.html#sysvar_validate_password_check_user_name) | 离开 | 在 |
| [`back_log`](server-system-variables.html#sysvar_back_log) | -1（自动调整大小）从：返回\_对数 = 50 +（最大值\_连接 / 5) | -1（自动调整大小）更改为：返回\_日志 = 最大值\_连接 |
| [`max_allowed_pa​​cket`](server-system-variables.html#sysvar_max_allowed_packet) | 4194304 (4MB) | 67108864 (64MB) |
| [`最大错误计数`](server-system-variables.html#sysvar_max_error_count) | 64 | 1024 |
| [`event_scheduler`](server-system-variables.html#sysvar_event_scheduler) | 离开 | 在 |
| [`table_open_cache`](server-system-variables.html#sysvar_table_open_cache) | 2000 | 4000 |
| [`log_error_verbosity`](server-system-variables.html#sysvar_log_error_verbosity) | 3（注） | 2（警告） |
| *InnoDB 更改* |  |  |
| [`innodb_undo_tablespaces`](innodb-parameters.html#sysvar_innodb_undo_tablespaces) | 0 | 2 |
| [`innodb_undo_log_truncate`](innodb-parameters.html#sysvar_innodb_undo_log_truncate) | 离开 | 在 |
| [`innodb_flush_method`](innodb-parameters.html#sysvar_innodb_flush_method) | 空值 | fsync (Unix)，无缓冲 (Windows) |
| [`innodb_autoinc_lock_mode`](innodb-parameters.html#sysvar_innodb_autoinc_lock_mode) | 1（连续） | 2（交错） |
| [`innodb_flush_neighbors`](innodb-parameters.html#sysvar_innodb_flush_neighbors) | 1（启用） | 0（禁用） |
| [`innodb_max_dirty_pages_pct_lwm`](innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct_lwm) | 0 (%) | 10 (%) |
| [`innodb_max_dirty_pages_pct`](innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct) | 75 (%) | 90 (%) |
| *性能架构更改* |  |  |
| `performance-schema-instrument='等待/锁定/元数据/sql/%=ON'` | 离开 | 在 |
| `性能模式仪器='内存/%=计数'` | 离开 | 计数 |
| `性能-模式-消费者-事件-事务-当前=ON` | 离开 | 在 |
| `性能-模式-消费者-事件-交易-历史=开启` | 离开 | 在 |
| `性能模式工具='事务%=ON'` | 离开 | 在 |
| *复制更改* |  |  |
| [`log_bin`](replication-options-binary-log.html#sysvar_log_bin) | 离开 | 在 |
| [`server_id`](replication-options.html#sysvar_server_id) | 0 | 1 |
| [`日志从更新`](replication-options-binary-log.html#sysvar_log_slave_updates) | 离开 | 在 |
| [`expire_logs_days`](replication-options-binary-log.html#sysvar_expire_logs_days) | 0 | 30 |
| [`主信息存储库`](replication-options-replica.html#sysvar_master_info_repository) | 文件 | 桌子 |
| [`中继日志信息存储库`](replication-options-replica.html#sysvar_relay_log_info_repository) | 文件 | 桌子 |
| [`事务写集提取`](replication-options-binary-log.html#sysvar_transaction_write_set_extraction) | 离开 | XXHASH64 |
| [`slave_rows_search_algorithms`](replication-options-replica.html#sysvar_slave_rows_search_algorithms) | 指数\_扫描，表格\_扫描 | 指数\_扫描，哈希\_扫描 |
| [`slave_pending_jobs_size_max`](replication-options-replica.html#sysvar_slave_pending_jobs_size_max) | 16M | 128M |
| [`gtid_executed_compression_period`](replication-options-gtids.html#sysvar_gtid_executed_compression_period) | 1000 | 0 |
| *组复制更改* |  |  |
| [`group_replication_autorejoin_tries`](group-replication-options.html#sysvar_group_replication_autorejoin_tries) | 0 | 3 |
| [`group_replication_exit_state_action`](group-replication-options.html#sysvar_group_replication_exit_state_action) | 中止\_服务器 | 读\_只要 |
| [`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout) | 0 | 5 |

有关已添加的选项或变量的更多信息，请参阅[MySQL 8.0 的选项/变量更改](https://dev.mysql.com/doc/mysqld-version-reference/en/optvar-changes-8-0.html)， 在里面*MySQL 服务器版本参考*.

以下部分解释了对默认值的更改以及它们可能对您的部署产生的任何影响。

**服务器默认值**

-   的默认值[`character_set_server`](server-system-variables.html#sysvar_character_set_server)系统变量和命令行选项[`--字符集服务器`](server-system-variables.html#sysvar_character_set_server)从改变`拉丁语1`到`utf8mb4`.这是服务器的默认字符集。目前，UTF8MB4 是 Web 的主要字符编码，这一变化使绝大多数 MySQL 用户的生活更轻松。从 5.7 升级到 8.0 不会更改任何现有数据库对象的任何字符集。但除非你指定`character_set_server`回到您以前的默认值或显式设置字符集，然后默认使用新的架构、表或列`utf8mb4`.我们建议您搬到`utf8mb4`只要有可能。

-   的默认值[`collat​​ion_server`](server-system-variables.html#sysvar_collation_server)系统变量和命令行参数[`--collat​​ion-server`](server-system-variables.html#sysvar_collation_server)从改变`latin1_swedish_ci`到`utf8mb4_0900_ai_ci`.这是服务器的默认排序规则，即字符集中字符的顺序。归类和字符集之间有一个链接，因为每个字符集都带有一个可能的归类列表。从 5.7 升级到 8.0 不会更改任何现有数据库对象的任何排序规则，但会对新对象生效。

-   的默认值[`显式默认值for_timestamp`](server-system-variables.html#sysvar_explicit_defaults_for_timestamp)系统变量从`离开`（MySQL 遗留行为）到`在`（SQL 标准行为）。这个选项最初是在 5.6 中引入的，并且是`离开`在 5.6 和 5.7 中。

-   的默认值[`optimizer_trace_max_mem_size`](server-system-variables.html#sysvar_optimizer_trace_max_mem_size)系统变量从`16KB`到`1MB`.旧的默认设置会导致优化器跟踪被截断以用于任何重要的查询。此更改确保对大多数查询有用的优化器跟踪。

-   的默认值[`validate_password_check_user_name`](validate-password-options-variables.html#sysvar_validate_password_check_user_name)系统变量从`离开`到`在`.这意味着当`验证密码`插件已启用，默认情况下它现在拒绝与当前会话用户名匹配的密码。

-   自动调整大小算法[`back_log`](server-system-variables.html#sysvar_back_log)系统变量已更改。autosize (-1) 的值现在设置为[`最大连接数`](server-system-variables.html#sysvar_max_connections), 大于计算的`50 + (max_connections / 5)`.这`back_log`在服务器无法跟上传入请求的情况下，将传入的 IP 连接请求排队。在最坏的情况下，与[`max_连接`](server-system-variables.html#sysvar_max_connections)尝试同时重新连接的客户端的数量，例如在网络故障后，可以对它们进行缓冲，并避免拒绝重试循环。

-   的默认值[`最大允许包数`](server-system-variables.html#sysvar_max_allowed_packet)系统变量已从`4194304`（4米）至`67108864`（64M）。这种较大的默认值的主要优点是，接收到有关插入或查询大于`最大允许包数`.它应该和最大的一样大[第11.3.4节，“BLOB和文本类型”](blob.html)你想用。要恢复到以前的行为，请设置`允许的最大数据包数=4194304`.

-   的默认值[`最大错误计数`](server-system-variables.html#sysvar_max_error_count)系统变量已从`64`到`1024`。这可以确保MySQL处理大量警告，例如涉及1000行的UPDATE语句，其中许多语句会给出转换警告。许多工具通常会批量更新，以帮助减少复制延迟。pt online schema change等外部工具默认为1000，gh ost默认为100。MySQL 8.0涵盖了这两个用例的完整错误历史。没有静态分配，因此此更改只会影响生成大量警告的语句的内存消耗。

-   的默认值[`事件调度程序`](server-system-variables.html#sysvar_event_scheduler)系统变量已从`关`到`在…上`。换句话说，默认情况下启用事件计划程序。这是SYS中新功能的启用码，例如“杀死空闲事务”。

-   的默认值[`表_打开_缓存`](server-system-variables.html#sysvar_table_open_cache)系统变量已从`2000`到`4000`.这是一个小改动，它增加了表访问的会话并发性。

-   的默认值[`日志错误详细`](server-system-variables.html#sysvar_log_error_verbosity)系统变量已从`3.`（注）至`2.`（警告）。其目的是在默认情况下减少MySQL 8.0错误日志的详细程度。

**InnoDB默认值**

-   **不相容的变化**的默认值[`innodb_undo_表空间`](innodb-parameters.html#sysvar_innodb_undo_tablespaces)系统变量已从`0`到`2.`。配置InnoDB使用的撤消表空间的数量。在MySQL 8.0中[`innodb_undo_表空间`](innodb-parameters.html#sysvar_innodb_undo_tablespaces)is 2和回滚段不能再在系统表空间中创建。因此，在这种情况下，您无法恢复到5.7行为。此更改的目的是能够自动截断撤消日志（请参阅下一项），回收长事务（偶尔）使用的磁盘空间，例如[**mysqldump**](mysqldump.html).

-   的默认值[`innodb_undo_log_truncate`](innodb-parameters.html#sysvar_innodb_undo_log_truncate)系统变量已从`关`到`在`.启用后，撤消超过定义的阈值的表空间[`innodb_max_undo_log_size`](innodb-parameters.html#sysvar_innodb_max_undo_log_size)被标记为截断。只有撤消表空间可以被截断。不支持截断驻留在系统表空间中的撤消日志。从 5.7 升级到 8.0 会自动将您的系统转换为使用 undo 表空间，在 8.0 中使用系统表空间不是一个选项。

-   的默认值[`innodb_flush_method`](innodb-parameters.html#sysvar_innodb_flush_method)系统变量从`空值`到`同步`在类 Unix 系统上和从`空值`到`无缓冲`在 Windows 系统上。这更像是一种术语和选项清理，没有任何实际影响。对于 Unix，这只是一个文档更改，因为默认值是`同步`也在 5.7 中（默认`空值`意思是`同步`）。同样在 Windows 上，[`innodb_flush_method`](innodb-parameters.html#sysvar_innodb_flush_method)默认`空值`意思是`async_unbuffered`在 5.7 中，默认替换`无缓冲`在 8.0 中，结合现有的默认值[`innodb_use_native_aio=ON`](innodb-parameters.html#sysvar_innodb_use_native_aio)有同样的效果。

-   **不兼容的变化**的默认值[`innodb_autoinc_lock_mode`](innodb-parameters.html#sysvar_innodb_autoinc_lock_mode)系统变量从`1`（连续）到`2`（交错）。将交错锁模式更改为默认设置反映了从基于语句的复制到基于行的复制作为默认复制类型的更改，这发生在 MySQL 5.7 中。*基于语句的复制*需要连续的自增锁模式来确保给定的 SQL 语句序列以可预测和可重复的顺序分配自增值，而*基于行的复制*对 SQL 语句的执行顺序不敏感。因此，已知此更改与基于语句的复制不兼容，并且可能会破坏某些依赖于顺序自动增量的应用程序或用户生成的测试套件。可以通过设置恢复以前的默认值`innodb_autoinc_lock_mode=1;`

-   的默认值[`innodb_flush_neighbors`](innodb-parameters.html#sysvar_innodb_flush_neighbors)系统变量从`1`（要启用`0`（禁用）。这样做是因为快速 IO (SSD) 现在是部署的默认设置。我们预计，对于大多数用户来说，这会带来很小的性能提升。使用速度较慢的硬盘驱动器的用户可能会看到性能损失，并鼓励通过设置恢复到以前的默认值`innodb_flush_neighbors=1`.

-   的默认值[`innodb_max_dirty_pages_pct_lwm`](innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct_lwm)系统变量从`0`（％） 到`10`(%)。和`innodb_max_dirty_pages_pct_lwm=10`, InnoDB 增加它的刷新活动时>10% 的缓冲池包含修改过的（“脏”）页面。此更改的目的是稍微权衡峰值吞吐量，以换取更一致的性能。

-   的默认值[`innodb_max_dirty_pages_pct`](innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct)系统变量从`75`（％） 到`90`(%)。此更改与更改为[`innodb_max_dirty_pages_pct_lwm`](innodb-parameters.html#sysvar_innodb_max_dirty_pages_pct_lwm)它们共同确保 InnoDB 的平滑刷新行为，避免刷新突发。要恢复到以前的行为，请设置`innodb_max_dirty_pages_pct=75`和`innodb_max_dirty_pages_pct_lwm=0`.

**性能架构默认值**

-   性能模式元数据锁定 (MDL) 检测默认打开。编译的默认值`performance-schema-instrument='等待/锁定/元数据/sql/%=ON'`从改变`离开`到`在`.这是在 SYS 中添加面向 MDL 的视图的促成因素。

-   性能模式内存检测默认打开。编译的默认值`性能模式仪器='内存/%=计数'`从改变`离开`到`计数`。这一点很重要，因为如果在服务器启动后启用了检测，则记帐是不正确的，并且您可能会因为缺少分配而获得负余额，但却捕获了免费的。

-   默认情况下，性能模式事务检测处于启用状态。的编译默认值`性能模式使用者事件事务当前=打开`,`performance schema consumer events transactions history=打开`和`性能架构工具=“事务%=打开”`从`关`到`在…上`.

**复制默认值**

-   的默认值[`木箱`](replication-options-binary-log.html#sysvar_log_bin)系统变量已从`关`到`在…上`。换句话说，默认情况下启用二进制日志记录。几乎所有的生产安装都启用了二进制日志，因为它用于复制和时间点恢复。因此，通过默认启用二进制日志，我们消除了一个配置步骤，以后启用它需要[**mysqld**](mysqld.html)重新启动。默认情况下启用它还可以提供更好的测试覆盖率，并且更容易发现性能下降。记住也要设定[`服务器id`](replication-options.html#sysvar_server_id)（参见以下更改）。8.0的默认行为就好像`./mysqld--log bin--server id=1`.如果你在8.0上，想要5.7的行为，你可以发布`./mysqld--跳过日志箱--服务器id=0`.

-   的默认值[`服务器id`](replication-options.html#sysvar_server_id)系统变量已从`0`到`1.`（结合对[`登录`](replication-options-binary-log.html#sysvar_log_bin))。可以使用此默认ID启动服务器，但实际上必须设置[`服务器id`](replication-options.html#sysvar_server_id)根据正在部署的复制基础架构，以避免重复的服务器ID。

-   的默认值[`日志从属更新`](replication-options-binary-log.html#sysvar_log_slave_updates)系统变量已从`关`到`在…上`。这会导致复制副本将复制的事件记录到自己的二进制日志中。此选项对于组复制是必需的，并且还可以确保在各种复制链设置中的正确行为，这已成为当今的标准。

-   的默认值[`过期_日志_天`](replication-options-binary-log.html#sysvar_expire_logs_days)系统变量已从`0`到`30`.新的违约`30`原因[**mysqld**](mysqld.html)定期清除超过30天的未使用二进制日志。此更改有助于防止在二进制日志上浪费过多的磁盘空间，而这些日志不再需要用于复制或恢复目的。旧价值观`0`禁用任何自动二进制日志清除。

-   的默认值[`主信息存储库`](replication-options-replica.html#sysvar_master_info_repository)和[`中继日志信息存储库`](replication-options-replica.html#sysvar_relay_log_info_repository)系统变量从`文件`到`桌子`。因此，在8.0中，复制元数据默认存储在InnoDB中。这提高了在默认情况下尝试实现崩溃安全复制的可靠性。

-   的默认值[`事务写入集提取`](replication-options-binary-log.html#sysvar_transaction_write_set_extraction)系统变量已从`关`到`XX64`。此更改默认情况下启用事务写入集。通过使用事务写入集，源代码需要做更多的工作来生成写入集，但结果有助于冲突检测。这是组复制的一个要求，新的默认设置使在源上启用二进制日志写入集并行化以加快复制变得容易。

-   的默认值[`从行搜索算法`](replication-options-replica.html#sysvar_slave_rows_search_algorithms)系统变量已从`索引扫描，表格扫描`到`索引扫描、哈希扫描`。此更改通过减少复制应用程序将更改应用于没有主键的表所需的表扫描次数，加快了基于行的复制。

-   的默认值[`从属\u待处理\u作业\u大小\u最大值`](replication-options-replica.html#sysvar_slave_pending_jobs_size_max)系统变量已从`16M`到`128M`。此更改增加了多线程副本可用的内存量。

-   的默认值[`gtid_执行_压缩_周期`](replication-options-gtids.html#sysvar_gtid_executed_compression_period)系统变量已从`1000`到`0`.此更改可确保`mysql。gtid_已执行`表仅在需要时隐式出现。

**组复制默认值**

-   的默认值[`组\u复制\u自动连接\u尝试`](group-replication-options.html#sysvar_group_replication_autorejoin_tries)从0更改为3，这意味着默认情况下启用自动重新加入。此系统变量指定成员在被驱逐或无法在被驱逐前联系到该组大多数成员时自动重新加入该组的尝试次数[`组\复制\无法访问\多数\超时`](group-replication-options.html#sysvar_group_replication_unreachable_majority_timeout)已达到设定值。

-   的默认值[`组\复制\退出\状态\操作`](group-replication-options.html#sysvar_group_replication_exit_state_action)从`中止服务器`到`只读`。这意味着当成员退出组时，例如在网络故障后，实例将变为只读，而不是关闭。

-   的默认值[`组\复制\成员\驱逐\超时`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)从0改为5，这意味着怀疑与该团体失去联系的成员在5秒检测期后5秒将被驱逐出境。

    这些默认值中的大多数对于开发和生产环境都相当好。有一个例外，我们决定保留新选项[`innodb_专用_服务器`](innodb-parameters.html#sysvar_innodb_dedicated_server)开始`关`尽管我们建议`在…上`用于生产环境。违约的原因`关`这会导致开发人员笔记本电脑等共享环境无法使用，因为这需要*全部的*它能找到的记忆。

    对于生产环境，我们建议设置[`innodb_专用_服务器`](innodb-parameters.html#sysvar_innodb_dedicated_server)到`在…上`.当设置为`在…上`以下InnoDB变量（如果没有明确指定）是基于可用内存自动调整的[`innodb_缓冲区_池_大小`](innodb-parameters.html#sysvar_innodb_buffer_pool_size), [`innodb_日志_文件_大小`](innodb-parameters.html#sysvar_innodb_log_file_size)和[`innodb_flush_方法`](innodb-parameters.html#sysvar_innodb_flush_method)看见[第15.8.12节，“为专用MySQL服务器启用自动配置”](innodb-dedicated-server.html).

    尽管新的默认设置是大多数用例的最佳配置选择，但使用现有5.7配置选择也有一些特殊情况和遗留原因。例如，有些人更喜欢升级到8.0，对他们的应用程序或操作环境进行尽可能少的更改。我们建议评估所有新的默认值，并尽可能多地使用。大多数新的默认设置都可以在5.7中测试，因此在升级到8.0之前，您可以在5.7生产环境中验证新的默认设置。对于需要旧5.7值的少数默认值，请在操作环境中设置相应的配置变量或启动选项。

    MySQL 8.0具有性能模式[`变量信息`](performance-schema-variables-info-table.html)表，其中显示了每个系统变量最近一次设置的来源及其值范围。这提供了对配置变量及其值的所有相关信息的SQL访问。