• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
    •
    位置： MySQL 8 中文手册 -> MySQL 服务器软件 -> 安装MySQL 8

    升级MySQL前准备工作

    本节介绍升级MySQL安装的步骤。

    升级是一个常见的过程，因为您可以获取相同MySQL版本系列中的错误修复程序或主要MySQL版本之间的重要功能。您首先在某些测试系统上执行此过程，以确保一切正常，然后在生产系统上执行。

    注意

    在下面的讨论中，必须使用具有管理特权的MySQL帐户运行的MySQL 命令包括在命令行上以指定MySQL 用户。需要密码的命令还包括一个选项。因为后面没有选项值，所以此类命令提示输入密码。在出现提示时输入密码，然后按Enter。-u rootrootroot-p-p

    可以使用mysql命令行客户端（连接root以确保您具有必需的特权）执行SQL语句。


    开始之前

    升级之前，请参见本节中的信息。执行任何建议的操作。

    • 了解升级期间可能发生的情况。请参见“ MySQL升级过程将升级什么”。

    • 通过创建备份来保护您的数据。备份应包括mysql系统数据库，该数据库包含MySQL数据字典表和系统表。请参见“数据库备份方法”。

      重要

      不支持从MySQL 8.0降级到MySQL 5.7，或从MySQL 8.0降级到以前的MySQL 8.0版本。唯一受支持的替代方法是还原升级前进行的备份。因此，必须在开始升级过程之前备份数据。

    • ，以确保支持您预期的升级路径。
    • 参见“ MySQL 8.0中的更改”，了解升级之前应注意的更改。某些更改可能需要采取措施。
    • 参见“ MySQL 8.0的新增功能”以了解不推荐使用和删除的功能。如果使用其中任何一项功能，则升级可能需要对这些功能进行更改。
    • 参见“在MySQL 8.0中添加，不建议使用或删除的服务器和状态变量及选项”。如果使用不建议使用或已删除的变量，则升级可能需要更改配置。
    • 参见发行说明，以获取有关修复，更改和新功能的信息。
    • 如果使用复制，请参见“升级复制设置”。

    • 升级过程因平台以及执行初始安装的方式而异。使用适用于当前MySQL安装的过程：

      • 对于非Windows平台上的基于二进制和基于软件包的安装，请参见“在Unix / Linux上升级MySQL二进制或基于软件包的安装”。

        注意

        对于受支持的Linux发行版，升级基于软件包的安装的首选方法是使用MySQL软件存储库（MySQL Yum存储库，MySQL APT存储库和MySQL SLES存储库）。

      • 有关使用MySQL Yum存储库在Enterprise Linux平台或Fedora上进行安装的信息，请参见“使用MySQL Yum存储库升级MySQL”。
      • 有关使用MySQL APT存储库在Ubuntu上进行安装的信息，
      • 有关使用MySQL SLES存储库在SLES上进行安装的信息，
      • 有关使用Docker执行的安装，
      • 有关在Windows上的安装，请参见“在Windows上升级MySQL”。
    • 如果您的MySQL安装中包含大量数据，这些数据在就地升级后可能需要很长时间才能转换，所以创建一个测试实例以评估所需的转换以及执行这些转换所涉及的工作可能会很有用。要创建测试实例，请复制一个MySQL实例，其中包含mysql数据库和其他没有数据的数据库。在测试实例上运行升级过程，以评估执行实际数据转换所涉及的工作。
    • 当您安装或升级到新版本的MySQL时，建议重建和重新安装MySQL语言界面。这适用于MySQL接口，例如PHP mysql扩展和Perl DBD::mysql模块。

    升级路径

    • 支持从MySQL 5.7升级到8.0。但是，仅在一般可用性（GA）版本之间支持升级。对于MySQL 8.0，要求您从MySQL 5.7 GA版本（5.7.9或更高版本）升级。不支持从非GA版本的MySQL 5.7升级。
    • 建议先升级到最新版本，再升级到下一版本。例如，在升级到MySQL 8.0之前，先升级到最新的MySQL 5.7版本。
    • 不支持跳过版本的升级。例如，不支持从MySQL 5.6直接升级到8.0。
    • 一旦发布系列达到通用（GA）状态，就支持在该发布系列内升级（从一个GA版本升级到另一个GA版本）。例如，从MySQL 8.0升级。x到8.0。y支持。（不支持涉及开发状态非GA版本的升级。）还支持跳过版本。例如，从MySQL 8.0升级。x到8.0。z支持。MySQL 8.0.11是MySQL 8.0发行系列中的第一个GA状态发行版。

    MySQL升级过程升级

    安装新版本的MySQL可能需要升级现有安装的以下部分：

    • 该mysql系统架构，其中包含表，通过它运行MySQL服务器所需的存储信息（参见5.3节，“MySQL的系统架构”）。mysql模式表分为两大类：

      • 数据字典表，用于存储数据库对象元数据。
      • 系统表（即剩余的非数据字典表），用于其他操作目的。

    • 其他模式，其中一些是内置的，可能被服务器视为“拥有”，而其他则不是：

      • 性能架构，INFORMATION_SCHEMA，ndbinfo，和sys模式。
      • 用户架构。

    两个不同的版本号与可能需要升级的安装部分相关联：

    • 数据字典版本。这适用于数据字典表。
    • 服务器版本，也称为MySQL版本。这适用于其他模式中的系统表和对象。

    在这两种情况下，适用于现有MySQL安装的实际版本都存储在数据字典中，而当前的预期版本将编译为MySQL的新版本。当实际版本低于当前预期版本时，必须将与该版本关联的安装的那些部分升级到当前版本。如果两个版本均指示需要升级，则必须首先进行数据字典升级。

    作为上述两个不同版本的反映，升级分两个步骤进行：

    • 步骤1：资料字典升级。

      此步骤升级：

      • 模式中的数据字典表mysql。如果实际数据字典版本低于当前预期版本，则服务器将创建具有更新定义的数据字典表，将持久化的元数据复制到新表中，用新表原子替换旧表，然后重新初始化数据字典。
      • 性能架构INFORMATION_SCHEMA和ndbinfo。

    • 步骤2：服务器升级。

      此步骤包括所有其他升级任务。如果现有MySQL安装的服务器版本低于新安装的MySQL版本，则必须升级所有其他服务器：

      • 模式中的系统表mysql（其余的非数据字典表）。
      • 该sys架构。
      • 用户架构。

    数据字典升级（步骤1）由服务器负责，服务器在启动时会根据需要执行此任务，除非使用阻止它执行此操作的选项进行调用。该选项--upgrade=NONE自MySQL 8.0.16起，--no-dd-upgrade早于MySQL 8.0.16。

    如果数据字典已过期，但是服务器无法对其进行升级，则服务器将无法运行并退出并出现错误。例如：

    [ERROR] [MY-013381] [Server] Server shutting down because upgrade is
required, yet prohibited by the command line option '--upgrade=NONE'.
[ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.

    MySQL 8.0.16中对步骤2的职责进行了一些更改：

    • 在MySQL 8.0.16之前，mysql_upgrade升级性能架构，INFORMATION_SCHEMA步骤2中描述的对象和对象。启动服务器后，期望DBA 手动调用mysql_upgrade。
    • 从MySQL 8.0.16开始，服务器执行以前由mysql_upgrade处理的所有任务。尽管升级仍然需要两步操作，但是服务器会同时执行这两项操作，从而简化了过程。

    根据要升级到的MySQL版本，就地升级和逻辑升级中的说明指示服务器是执行所有升级任务还是在服务器启动后还必须调用mysql_upgrade。

    注意

    由于服务器INFORMATION_SCHEMA从MySQL 8.0.16开始升级了Performance Schema 和第2步中描述的对象，因此该版本不再需要mysql_upgrade并已弃用，并将在以后的MySQL版本中将其删除。

    尽管可能需要不同的命令选项才能达到特定的效果，但第2步期间发生的大多数方面与MySQL 8.0.16之前的版本相同。

    从MySQL 8.0.16开始，--upgrade服务器选项控制服务器在启动时是否以及如何执行自动升级：

    • 不带选项或带--upgrade=AUTO，服务器将升级它确定为过期的任何内容（步骤1和2）。
    • 使用--upgrade=NONE，服务器不进行任何升级（跳过步骤1和2），但是如果必须升级数据字典，也会退出并出现错误。不能使用过期的数据字典来运行服务器。服务器坚持要升级或退出。
    • 使用--upgrade=MINIMAL，服务器将升级数据字典，性能架构和INFORMATION_SCHEMA，如果需要的话（步骤1）。请注意，使用此选项升级之后，将无法启动组复制，因为复制内部所依赖的系统表未更新，并且降低的功能在其他方面也很明显。
    • 使用--upgrade=FORCE，服务器将升级数据字典，性能模式和INFORMATION_SCHEMA，如果需要的话（步骤1），并强制升级其他所有内容（步骤2）。期望使用此选项启动服务器会花费更长的时间，因为服务器会检查所有架构中的所有对象。

    FORCE如果服务器认为不必要执行第2步操作，则此操作很有用。一种方式FORCE不同于AUTO是用FORCE，服务器将重新创建系统表，如帮助表或如果缺少时区表。

    以下列表显示了MySQL 8.0.16之前的升级命令以及MySQL 8.0.16及更高版本的等效命令：

    • 执行常规升级（必要时执行步骤1和2）：

      • 在MySQL 8.0.16之前：mysqld，后跟mysql_upgrade
      • 从MySQL 8.0.16开始：mysqld

    • 根据需要仅执行步骤1：

      • 在此之前的MySQL 8.0.16：这是不可能的执行步骤1中的所有升级任务，同时排除那些在步骤2中描述。然而，你能避免升级用户模式和sys使用模式的mysqld，然后mysql_upgrade与--upgrade-system-tables和--skip-sys-schem 选项。
      • 从MySQL 8.0.16开始：mysqld--upgrade = MINIMAL

    • 根据需要执行步骤1，然后强制执行步骤2：

      • 在MySQL 8.0.16之前：mysqld，后跟mysql_upgrade --force
      • 从MySQL 8.0.16开始：mysqld--upgrade = FORCE

    在MySQL 8.0.16之前，某些mysql_upgrade选项会影响其执行的操作。下表显示了--upgrade从MySQL 8.0.16开始使用的服务器选项值，以实现类似的效果。（这些不一定完全相同，因为给定的--upgrade期权价值可能会有其他影响。）

    mysql_upgrade选项服务器选件
    --skip-sys-schem --upgrade=NONE要么--upgrade=MINIMAL
    --upgrade-system-tables--upgrade=NONE要么--upgrade=MINIMAL
    --force--upgrade=FORCE

    有关升级步骤2中发生的事情的其他说明：

    • sys如果未安装架构，则第2步将安装该架构，否则将其升级到当前版本。如果sys存在一个架构但没有version视图，那么会发生错误，并假设该架构的缺失表示用户创建的架构：

      A sys schema exists with no sys.version view. If
you have a user created sys schema, this must be renamed for the
upgrade to succeed.

      在这种情况下，要进行升级，请先删除或重命名现有sys架构。然后再次执行升级过程。（可能有必要强制执行步骤2。）

      为防止sys模式检查：

      • 从MySQL 8.0.16开始：使用--upgrade=NONE或--upgrade=MINIMAL选项启动服务器。
      • 在MySQL 8.0.16之前：使用该选项调用mysql_upgrade--skip-sys-schem 。

    • 步骤2根据需要处理所有用户模式中的所有表。表检查可能需要很长时间才能完成。每个表都被锁定，因此在处理它时其他会话无法使用。检查和修复操作可能很耗时，特别是对于大桌子。表检查使用语句的FOR UPGRADE选项CHECK TABLE。有关此选项的含义的详细信息，请参见“ CHECK TABLE语句”。

      为了防止表格检查：

      • 从MySQL 8.0.16开始：使用--upgrade=NONE或--upgrade=MINIMAL选项启动服务器。
      • 在MySQL 8.0.16之前：使用该选项调用mysql_upgrade--upgrade-system-tables。

      强制检查表：

      • 从MySQL 8.0.16开始：使用--upgrade=FORCE选项启动服务器。
      • 在MySQL 8.0.16之前：使用该选项调用mysql_upgrade--force。

    • 步骤2将MySQL版本号保存mysql_upgrade_info在data目录中命名的文件中。

      要忽略mysql_upgrade_info文件并执行检查，无论如何：

      • 从MySQL 8.0.16开始：使用--upgrade=FORCE选项启动服务器。
      • 在MySQL 8.0.16之前：使用该选项调用mysql_upgrade--force。
      注意

      该mysql_upgrade_info文件已弃用，并将在将来的MySQL版本中删除。

    • 步骤2使用当前的MySQL版本号标记所有已检查和已修复的表。这样可确保下次使用相同版本的服务器进行升级检查时，可以确定是否需要再次检查或修复给定的表。
    • 步骤2升级系统表以确保它们具有当前结构。无论服务器还是mysql_upgrade执行该步骤，都是如此。关于帮助表和时区表的内容，mysql_upgrade不会加载这两种类型的表，而服务器会加载帮助表，但不会加载时区表。（也就是说，在MySQL 8.0.16之前，服务器仅在数据目录初始化时加载帮助表。从MySQL 8.0.16开始，它在初始化和升级时加载帮助表。）加载时区表的过程它取决于平台，需要DBA做出决策，因此无法自动完成。

    MySQL 8.0中的更改

    升级到MySQL 8.0之前，请参见本节中描述的更改，以识别适用于当前MySQL安装和应用程序的更改。执行任何建议的操作。

    标为“不兼容的更改”的更改与MySQL的早期版本不兼容，在升级之前可能需要引起您的注意。我们的目的是避免这些更改，但是有时它们对于纠正比发行版之间的不兼容性更严重的问题是必要的。如果适用于您的安装的升级问题涉及不兼容，请按照说明中给出的说明进行操作。

    • 数据字典更改
    • caching_sha2_password作为首选身份验证插件
    • 配置变更
    • 服务器变更
    • InnoDB的变化
    • SQL变更

    数据字典更改

    MySQL Server 8.0包含一个全局数据字典，该字典包含有关事务表中数据库对象的信息。在先前的MySQL系列中，字典数据存储在元数据文件和非事务系统表中。因此，升级过程要求您通过检查特定的先决条件来验证安装的升级准备情况。有关更多信息，启用数据字典的服务器需要一些常规的操作差异；

    caching_sha2_password作为首选身份验证插件

    该caching_sha2_password和sha256_password认证插件提供比更安全的密码加密mysql_native_password插件，并caching_sha2_password提供了比更好的性能sha256_password。由于的这些优越的安全性和性能caching_sha2_password，它是MySQL 8.0的首选身份验证插件，也是默认的身份验证插件，而不是mysql_native_password。此更改会影响服务器和libmysqlclient客户端库：

    • 对于服务器，default_authentication_plugin系统变量的默认值从更改mysql_native_password为caching_sha2_password。

      此更改仅适用于在安装或升级到MySQL 8.0或更高版本后创建的新帐户。对于升级安装中已经存在的帐户，其身份验证插件保持不变。希望切换到的现有用户caching_sha2_password可以使用以下ALTER USER语句：

      ALTER USER user
IDENTIFIED WITH caching_sha2_password
BY 'password';
    • 该libmysqlclient库被视为caching_sha2_password默认的身份验证插件，而不是mysql_native_password。

    以下各节讨论了更重要角色的含义caching_sha2_password：

    • caching_sha2_password兼容性问题和解决方案
    • caching_sha2_password兼容的客户端和连接器
    • caching_sha2_password和根管理帐户
    • caching_sha2_password和复制
    caching_sha2_password兼容性问题和解决方案
    重要

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

    [mysqld]
default_authentication_plugin=mysql_native_password

    该设置使8.0之前的客户端可以连接到8.0服务器，直到安装时使用的客户端和连接器升级为caching_sha2_password。但是，该设置应被视为临时的，而不是长期的或永久的解决方案，因为它会导致使用该设置创建的新帐户有效地放弃所提供的改进的身份验证安全性caching_sha2_password。

    使用可以caching_sha2_password提供比mysql_native_password（并因此改善了客户端连接身份验证）更安全的密码哈希。但是，它也具有兼容性影响，可能会影响现有的MySQL安装：

    • 尚未更新的客户端和连接器caching_sha2_password可能无法连接到配置caching_sha2_password为默认身份验证插件的MySQL 8.0服务器，甚至无法使用不通过进行身份验证的帐户caching_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]

      有关编写连接器以妥善处理来自服务器的未知默认身份验证插件请求的信息，请参阅身份验证插件连接器编写注意事项。

    • 使用进行身份验证的帐户的客户端caching_sha2_password必须使用安全连接（使用TLS / SSL凭据通过TCP进行连接，Unix套接字文件或共享内存）或支持使用RSA密钥对进行密码交换的未加密连接。此安全性要求不适用于mysql_native_passsword，因此切换到caching_sha2_password可能需要其他配置（请参见“缓存SHA-2可插拔身份验证”）。但是，默认情况下，MySQL 8.0中的客户端连接更喜欢使用TLS / SSL，因此已经符合该首选项的客户端可能不需要其他配置。
    • 尚未更新了解的客户端和连接器caching_sha2_password无法连接到进行身份验证的帐户，caching_sha2_password因为它们无法识别此插件有效。（这是如何应用客户端/服务器身份验证插件兼容性要求的特定实例，如身份验证插件客户端/服务器兼容性中所述。）要变通解决此问题，请针对libmysqlclientMySQL 8.0或更高版本重新链接客户端，或获取可识别出更新的连接器caching_sha2_password。
    • 因为caching_sha2_password现在它也是libmysqlclient客户端库中的默认身份验证插件，所以身份验证需要在客户端/服务器协议中进行一次额外的往返，才能从MySQL 8.0客户端连接到使用mysql_native_password该帐户的帐户（以前的默认身份验证插件），除非使用一个--default-auth=mysql_native_password选择。

    libmysqlclient8.0之前版本的MySQL 的客户端库能够连接到MySQL 8.0服务器（使用进行身份验证的帐户除外caching_sha2_password）。这意味着基于8.0之前版本的客户端libmysqlclient也应该能够连接。例子：

    • 标准MySQL客户端（例如mysql和mysqladmin）是libmysqlclient基于-的。
    • Perl DBI的DBD :: mysql驱动程序是libmysqlclient基于-的。
    • MySQL Connector / Python具有基于C的C扩展模块libmysqlclient。要使用它，请use_pure=False在连接时包括该选项。

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

    • 升级之前，使用DBD :: mysql的DBI脚本可以连接到MySQL 8.0服务器，但使用进行身份验证的帐户除外caching_sha2_password。
    • 升级后，相同的脚本也可以使用caching_sha2_password帐户。

    但是，发生上述结果是因为libmysqlclient8.0.4之前的MySQL 8.0安装的实例与二进制兼容：它们都使用共享库主版本号21。对于libmysqlclient从MySQL 5.7或更早版本链接的客户端，它们使用以下方式链接到共享库：与二进制不兼容的其他版本号。在这种情况下，必须libmysqlclient从8.0.4或更高版本重新编译客户端，以与MySQL 8.0服务器和caching_sha2_password帐户完全兼容。

    MySQL Connector / J 5.1至8.0.8能够连接到MySQL 8.0服务器，但使用进行身份验证的帐户除外caching_sha2_password。（连接到caching_sha2_password帐户需要Connector / J 8.0.9或更高版本。）

    使用客户端/服务器协议以外的其他实现的客户端libmysqlclient可能需要升级到可以理解新身份验证插件的较新版本。例如，在PHP中，MySQL连接通常基于mysqlnd，目前尚不了解caching_sha2_password。在提供更新版本之前mysqlnd，使PHP客户端连接到MySQL 8.0的方法是将服务器重新配置为恢复mysql_native_password为默认身份验证插件，如前所述。

    如果客户端或连接器支持显式指定默认身份验证插件的选项，请使用它命名除之外的插件caching_sha2_password。例子：

    • 一些MySQL客户端支持一个--default-auth选项。（标准的MySQL客户端（例如mysql和mysqladmin）支持此选项，但如果没有该选项，则可以成功连接到8.0服务器。但是，其他客户端也可以支持类似的选项。如果是这样，则值得尝试。）
    • 使用libmysqlclientC API的程序可以使用选项调用该mysql_options()函数MYSQL_DEFAULT_AUTH。
    • 使用客户端/服务器协议的本机Python实现的MySQL Connector / Python脚本可以指定 uth_plugin连接选项。（或者，使用连接器/ Python C扩展，它可以连接到MySQL 8.0服务器，而无需 uth_plugin。）
    caching_sha2_password兼容的客户端和连接器

    如果有可用的客户端或连接器已被更新以了解caching_sha2_password，则使用它是确保与配置caching_sha2_password为默认身份验证插件的MySQL 8.0服务器连接时兼容性的最佳方法。

    这些客户端和连接器已升级为支持caching_sha2_password：

    • libmysqlclientMySQL 8.0（8.0.4或更高版本）中的客户端库。标准MySQL客户端（例如mysql和mysqladmin）是libmysqlclient基于-的，因此它们也兼容。
    • libmysqlclientMySQL 5.7（5.7.23或更高版本）中的客户端库。标准MySQL客户端（例如mysql和mysqladmin）是libmysqlclient基于-的，因此它们也兼容。
    • MySQL Connector / C + + 1.1.11或更高版本或8.0.7或更高版本。
    • MySQL Connector / J 8.0.9或更高版本。
    • MySQL Connector / NET 8.0.10或更高版本（通过经典的MySQL协议）。
    • MySQL Connector / Node.js 8.0.9或更高版本。

    • PHP：X DevAPI PHP扩展（mysql_xdevapi）支持caching_sha2_password。

      PHP：PDO_MySQL和ext / mysqli扩展不支持caching_sha2_password。另外，当与7.1.16之前的PHP版本和7.2.4之前的PHP 7.2一起使用时，default_authentication_plugin=caching_sha2_password即使caching_sha2_password未使用它们也无法连接。

    caching_sha2_password和根管理帐户

    对于升级到MySQL 8.0，身份验证插件的现有帐户（包括'root'@'localhost'管理帐户的插件）保持不变。

    对于新安装的MySQL 8.0，在初始化数据目录（使用“初始化数据目录”中的说明）时，将'root'@'localhost'创建该帐户，并且caching_sha2_password默认情况下使用该帐户。要在数据目录初始化后连接到服务器，必须使用支持的客户端或连接器caching_sha2_password。如果可以执行此操作，但希望在安装后root使用该帐户mysql_native_password，请照常安装MySQL并初始化数据目录。然后以以下方式连接到服务器，root并使用ALTER USER以下方法更改帐户身份验证插件和密码：

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

    如果您使用的客户端或连接器尚不支持caching_sha2_password，则可以使用修改后的数据目录初始化过程，该过程将在创建root帐户后mysql_native_password立即将其与之关联。为此，请使用以下两种技术之一：

    • --default-authentication-plugin=mysql_native_password与--initialize或一起提供一个选项--initialize-insecure。
    • 在选项文件中设置default_authentication_plugin为mysql_native_password，然后使用--defaults-file选项--initialize或或命名该选项文件--initialize-insecure。（在这种情况下，如果继续使用该选项文件进行后续服务器启动，则将使用创建新帐户，mysql_native_password而不是caching_sha2_password除非您default_authentication_plugin从选项文件中删除该设置，否则创建新帐户。）
    caching_sha2_password和复制

    在所有服务器都已升级到MySQL 8.0.4或更高版本的复制方案中，与主/主服务器的从/副本连接可以使用通过进行身份验证的帐户caching_sha2_password。对于此类连接，与使用使用以下方式进行身份验证的帐户的其他客户端相同，要求相同caching_sha2_password：使用安全连接或基于RSA的密码交换。

    要连接到caching_sha2_password用于主/从复制的帐户：

    • 使用以下任何CHANGE MASTER TO选项：

      MASTER_SSL = 1
GET_MASTER_PUBLIC_KEY = 1
MASTER_PUBLIC_KEY_PATH='path to RSA public key file'
    • 或者，如果在服务器启动时提供了必需的密钥，则可以使用与RSA公用密钥相关的选项。

    要连接到caching_sha2_password组复制帐户：

    • 对于使用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并且NDB是唯一提供MySQL 8.0支持的本机分区处理程序的存储引擎。在升级服务器之前，必须更改使用任何其他存储引擎的分区表（将其转换为InnoDB或NDB，或删除其分区），否则此后将无法使用。

      有关将MyISAM表转换为的信息InnoDB，请参见“将表从MyISAM转换为InnoDB”。

      在没有这种支持的情况下，使用存储引擎将导致分区表的表创建语句失败，并在MySQL 8.0中出现错误（ER_CHECK_NOT_IMPLEMENTED）。如果从使用mysqldump在MySQL 5.7（或更早版本）中创建的转储文件中将数据库导入 MySQL 8.0服务器，则必须确保通过删除对分区的任何引用来创建分区表的任何语句也未指定不受支持的存储引擎。，或者将存储引擎指定为InnoDB或允许将其InnoDB默认设置为。

      注意

      “为升级做准备”中给出的过程描述了如何识别在升级到MySQL 8.0之前必须更改的分区表。

      有关更多信息，请参见“与存储引擎有关的分区限制”。

    • 不兼容的更改：几个服务器错误代码未使用且已删除（有关列表，请参阅 MySQL 8.0中删除的功能）。专门针对其中任何一个进行测试的应用程序都应该更新。

    • 重要更改：默认字符集已从更改latin1为utf8mb4。这些系统变量会受到影响：

      • character_set_server和character_set_database系统变量的默认值已从更改latin1为utf8mb4。
      • collation_server和collation_database系统变量的默认值已从更改latin1_swedish_ci为utf8mb4_0900_ai_ci。

      结果，除非指定了明确的字符集和排序规则，否则新对象的默认字符集和排序规则与以前不同。这包括数据库和其中的对象，例如表，视图和存储的程序。假设使用先前的默认值，保留它们的一种方法是使用my.cnf文件中的以下行启动服务器：

      [mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ci

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

    • 不兼容的更改：从MySQL 8.0.11开始，禁止lower_case_table_names使用与初始化服务器时使用的设置不同的设置来启动服务器。该限制是必要的，因为各种数据字典表字段使用的归类基于lower_case_table_names初始化服务器时定义的设置，并且使用其他设置重新启动服务器会导致标识符排序和比较方式的不一致。

    服务器变更

    • 在MySQL 8.0.11中，已删除了一些与帐户管理有关的不赞成使用的功能，例如使用该GRANT语句修改用户帐户的非特权特征，NO_AUTO_CREATE_USERSQL模式，PASSWORD()函数和old_passwords系统变量。

      从MySQL 5.7复制到引用这些已删除功能的语句的8.0可能会导致复制失败。使用任何已删除功能的应用程序都应进行修改，以避免使用它们，并尽可能使用替代方法，如MySQL 8.0中已删除功能中所述。

      为了避免在MySQL 8.0上启动失败，请NO_AUTO_CREATE_USER从sql_modeMySQL选项文件中的系统变量设置中删除任何实例。

      将包含已NO_AUTO_CREATE_USER存储程序定义中的SQL模式的转储文件加载到MySQL 8.0服务器中会导致失败。从MySQL 5.7.24和MySQL 8.0.13开始，mysqldumpNO_AUTO_CREATE_USER从存储的程序定义中删除。mysqldump必须手动修改使用早期版本创建的转储文件，以删除的实例NO_AUTO_CREATE_USER。

    • 在MySQL 8.0.11，这些过时的兼容性SQL模式被拆除：DB2，MAXDB，MSSQL，MYSQL323，MYSQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。它们不能再分配给sql_mode系统变量或用作mysqldump--compatible选项的允许值。

      删除MAXDB意味着TIMESTAMP数据类型为CREATE TABLE或ALTER TABLE不再被视为DATETIME。

      从MySQL 5.7复制到引用已删除的SQL模式的语句的8.0可能会导致复制失败。这包括复制CREATE在当前sql_mode值包括任何已删除模式时执行的存储程序（存储过程和函数，触发器和事件）的语句。使用任何已删除模式的应用程序都应进行修改以避免它们。

    • 从MySQL 8.0.3开始，空间数据类型允许使用SRID属性，以明确指示存储在列中的值的空间参考系统（SRS）。请参见“空间数据类型”。

      具有显式SRID属性的空间列受SRID限制：该列仅接受具有该ID的值，并且SPATIAL列上的索引将成为优化程序使用的对象。优化器将忽略SPATIAL没有SRID属性的空间列上的索引。请参见“空间索引优化”。如果希望优化器考虑SPATIAL不受SRID限制的空间列的索引，则应修改每个这样的列：

      • 验证列中的所有值都具有相同的SRID。要确定几何列中包含的SRID col_name，请使用以下查询：

        SELECT DISTINCT ST_SRID(col_name) FROM tbl_name;

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

      • 重新定义该列以具有显式SRID属性。
      • 重新创建SPATIAL索引。
    • 由于空间功能名称空间的更改（实现了ST_执行精确操作MBR的功能的前缀或基于最小边界矩形执行操作的功能的前缀），在MySQL 8.0.0中删除了一些空间功能。在生成的列定义中使用删除的空间函数可能会导致升级失败。升级之前，运行mysqlcheck --check-upgrade删除已删除的空间函数，并用其ST_或MBR命名的替换项替换找到的任何空间函数。有关已删除的空间函数的列表，请参阅MySQL 8.0中已删除的功能。。
    • 当执行就地升级到MySQL 8.0.3或更高版本时，BACKUP_ADMIN特权将自动授予具有RELOAD特权的用户。

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

      • SET @@SESSION.binlog_format如果会话具有任何打开的临时表，则不能使用。
      • SET @@global.binlog_format并且SET @@persist.binlog_format如果任何复制通道具有任何打开的临时表，则不能使用。SET @@persist_only.binlog_format如果复制通道具有打开的临时表，则允许使用该方法，因为与不同PERSIST，PERSIST_ONLY它不会修改运行时全局系统变量值。
      • SET @@global.binlog_format并且SET @@persist.binlog_format如果正在运行任何复制通道应用程序，则无法使用。这是因为更改仅在重新启动其应用程序时才在复制通道上生效，此时复制通道可能具有打开的临时表。此行为比以前更严格。SET @@persist_only.binlog_format如果有任何复制渠道申请者正在运行，则允许使用。

    InnoDB的变化

    • INFORMATION_SCHEMA基于InnoDB系统表的视图被数据字典表上的内部系统视图替换。受影响的InnoDBINFORMATION_SCHEMA视图已重命名：

      表2.15重命名的InnoDB信息架构视图

      旧名称新名字
      INNODB_SYS_COLUMNSINNODB_COLUMNS
      INNODB_SYS_DATAFILESINNODB_DATAFILES
      INNODB_SYS_FIELDSINNODB_FIELDS
      INNODB_SYS_FOREIGNINNODB_FOREIGN
      INNODB_SYS_FOREIGN_COLSINNODB_FOREIGN_COLS
      INNODB_SYS_INDEXESINNODB_INDEXES
      INNODB_SYS_TABLESINNODB_TABLES
      INNODB_SYS_TABLESPACESINNODB_TABLESPACES
      INNODB_SYS_TABLESTATSINNODB_TABLESTATS
      INNODB_SYS_VIRTUALINNODB_VIRTUAL

      升级到MySQL 8.0.3或更高版本后，请更新所有引用先前InnoDBINFORMATION_SCHEMA视图名称的脚本。

    • 与MySQL捆绑在一起的zlib库版本从1.2.3版本提高到1.2.11版本。

      compressBound()zlib 1.2.11中的zlib 函数返回的压缩给定字节长度所需的缓冲区大小的估计值比zlib 1.2.3版中的缓冲区估计值稍高。该compressBound()函数由InnoDB确定在创建压缩InnoDB表或在压缩InnoDB表中插入和更新行时所允许的最大行大小的函数调用。其结果是，CREATE TABLE ... ROW_FORMAT=COMPRESSED，INSERT，和UPDATE与行大小的操作非常接近成功在早期版本中，现在可能会失败的最大行大小。为避免此问题，请CREATE TABLE对压缩的测试语句进行压缩InnoDB升级之前，MySQL 8.0测试实例上具有大行的表。

    • 引入此--innodb-directories功能后，应将使用绝对路径创建的每表文件和常规表空间文件的位置或数据目录外部的位置添加到innodb_directories参数值。否则，InnoDB将无法在恢复过程中找到这些文件。要参见表空间文件位置，请查询INFORMATION_SCHEMA.FILES表：

      SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

    • 撤消日志不能再驻留在系统表空间中。在MySQL 8.0中，默认情况下，撤消日志位于两个撤消表空间中。有关更多信息，请参见“撤消表空间”。

      从MySQL 5.7升级到MySQL 8.0时，MySQL 5.7实例中存在的所有撤消表空间都将被删除，并由两个新的默认撤消表空间代替。默认撤消表空间在innodb_undo_directory变量定义的位置中创建。如果innodb_undo_directory未定义变量，则在数据目录中创建撤消表空间。从MySQL 5.7升级到MySQL 8.0需要缓慢关闭，以确保MySQL 5.7实例中的撤消表空间为空，从而可以安全地删除它们。

      从早期版本的MySQL 8.0升级到MySQL 8.0.14或更高版本时，由于innodb_undo_tablespaces设置大于2而导致升级前实例中存在的撤消表空间被视为用户定义的撤消表空间，可以将其撤消并删除升级后分别使用ALTER UNDO TABLESPACE和DROP UNDO TABLESPACE语法。在MySQL 8.0版本系列中进行升级可能并不总是需要缓慢的关闭，这意味着现有的撤消表空间可能包含撤消日志。因此，升级过程不会删除现有的撤消表空间。

    • 不兼容的更改：从MySQL 8.0.17开始，该CREATE TABLESPACE ... ADD DATAFILE子句不允许循环目录引用。例如，/../以下语句中的循环目录引用（）是不允许的：

      CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd ' ny_directory/../ts1.ibd';

      限制是一个例外，在Linux上，如果先前的目录是符号链接，则允许循环目录引用。例如，如果 ny_directory是符号链接，则允许上面示例中的数据文件路径。（仍然允许数据文件路径以“../”开头。）

      为了避免升级问题，请在升级到MySQL 8.0.17或更高版本之前，从表空间数据文件路径中删除所有循环目录引用。要检查表空间路径，请查询INFORMATION_SCHEMA.INNODB_DATAFILES表。

    • 由于MySQL 8.0.14中引入了回归功能，因此对于具有分区表和的实例，在区分大小写的文件系统上从MySQL 5.7或MySQL 8.0.14之前的MySQL 8.0版本到MySQL 8.0.16的就地升级失败lower_case_table_names=1。失败是由与分区表文件名有关的大小写不匹配问题引起的。恢复了引入回归的修复程序，该修复程序允许从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.14、8.0.15或8.0.16到MySQL 8.0.17的就地升级失败，并在将二进制文件或软件包升级到MySQL 8.0.17（如果已分区）后启动服务器时，出现以下错误表存在和lower_case_table_names=1：

      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. 重新启动服务器--upgrade=force以强制进行升级操作。

      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在每个重命名的表上运行，以更新mysql.innodb_index_stats和mysql.innodb_table_stats表中的优化器统计信息。

      由于MySQL 8.0.14、8.0.15和8.0.16版本中仍然存在回归，因此在这种情况下，不支持将分区表从MySQL 8.0.14、8.0.15或8.0.16导入MySQL 8.0.17。敏感文件系统lower_case_table_names=1。尝试这样做会导致出现“表缺少表空间”错误。

    • 当为表分区构造表空间名称和文件名时，MySQL使用定界符字符串。阿“#p#”分隔符字符串先于分区名，和一个“#sp#”分隔符字符串先于子分区的名称，如图所示：

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

      从历史上看，分隔符字符串在区分大小写的文件系统（例如Linux）上是大写（#P#和#SP#），在不区分大小写的文件系统（例如Windows）上是小写（#p#和#sp#）。从MySQL 8.0.19开始，分隔符字符串在所有文件系统上均为小写。此更改可防止在区分大小写和不区分大小写的文件系统之间迁移数据目录时出现问题。大写定界符字符串不再使用。

      此外，现在可以根据用户指定的分区或子分区名称生成分区表空间名称和文件名（可以用大写或小写指定），而无需考虑lower_case_table_names设置，以确保不区分大小写。例如，如果使用name创建表分区PART_1，则表空间名称和文件名以小写形式生成：

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

      在升级过程中，MySQL会根据需要检查和修改：

      • 在磁盘上和数据字典中对文件名进行分区，以确保小写的分隔符和分区名。
      • 对数据字典中的元数据进行分区，以解决以前的错误修复所引入的相关问题。
      • InnoDB以前的错误修复所引入的相关问题的统计数据。

      在表空间导入操作期间，需要检查并修改磁盘上的分区表空间文件名，以确保使用小写的分隔符和分区名。

    SQL变更

    • 不兼容的更改：自MySQL 8.0.13起，不赞成使用的子句ASC或DESC限定词GROUP BY已被删除。先前依赖于GROUP BY排序的查询所产生的结果可能与以前的MySQL版本不同。要产生给定的排序顺序，请提供一个ORDER BY子句。

      MySQL 8.0.12或更低版本中对子句使用ASC或DESC限定符的查询和存储程序定义GROUP BY应进行修改。否则，升级到MySQL 8.0.13或更高版本可能会失败，可能会复制到MySQL 8.0.13或更高版本的从属服务器。

    • 有些关键字可能在MySQL 8.0中保留，而在MySQL 5.7中未保留。请参见“关键字和保留字”。这可能导致以前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引号。请参见“模式对象名称”。
    • 升级后，建议您测试应用程序代码中指定的优化器提示，以确保仍需要这些提示来实现所需的优化策略。优化器增强有时可能使某些优化器提示不必要。在某些情况下，不必要的优化器提示甚至可能适得其反。

    • 不兼容的更改：在MySQL 5.7中，FOREIGN KEY为InnoDB不带子句的表指定定义，或不带关键字的关键字导致使用生成的约束名称。在MySQL 8.0中，该行为发生了变化，使用了值而不是生成的名称。因为约束名称对于每个架构（数据库）必须是唯一的，所以由于外键索引名称不是每个架构唯一，因此更改会导致错误。为了避免此类错误，MySQL 8.0.16中已恢复了新的约束命名行为，并且CONSTRAINT symbolCONSTRAINTsymbolInnoDBInnoDBFOREIGN KEY index_nameInnoDB再次使用生成的约束名称。

      为了与保持一致InnoDB，NDB如果未指定该子句，或者指定的关键字不带，则基于MySQL 8.0.16或更高版本的MySQL使用生成的约束名称。基于MySQL 5.7和更低版本的MySQL 8.0发行版使用该值。CONSTRAINT symbolCONSTRAINTsymbolNDBFOREIGN KEY index_name

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

    准备安装进行升级

    在升级到最新的MySQL 8.0版本之前，请通过执行以下所述的初步检查，确保当前MySQL 5.7或MySQL 8.0服务器实例的升级准备就绪。否则升级过程可能会失败。

    可以使用MySQL Shell升级检查器实用程序执行相同的检查和其他检查。有关更多信息，请参见 Upgrade Checker Utility。

    初步检查：

    1. 不得出现以下问题：

      • 不得有使用过时数据类型或功能的表。

        不支持就地升级到MySQL 8.0，如果表包含在预5.6.4格式老时间列（TIME，DATETIME，和TIMESTAMP列不为小数秒精度支持）。如果您的表仍然使用旧的时间列格式，请REPAIR TABLE在尝试就地升级到MySQL 8.0之前使用对其进行升级。有关更多信息，请参阅服务器更改。

      • 不能有孤立.frm文件。
      • 触发器不能有遗漏或空定义者或无效的创作环境（由表示character_set_client，collation_connection，Database Collation属性显示的SHOW TRIGGERS或INFORMATION_SCHEMATRIGGERS表）。任何此类触发器都必须转储并还原以解决问题。

      要检查这些问题，请执行以下命令：

      mysqlcheck -u root -p --all-databases --check-upgrade

      如果mysqlcheck报告任何错误，请更正问题。

    2. 不得有使用不具有本机分区支持的存储引擎的分区表。要标识此类表，请执行以下查询：

      SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE NOT IN ('innodb', 'ndbcluster')
AND CREATE_OPTIONS LIKE '%partitioned%';

      查询所报告的任何表都必须更改为可以使用InnoDB或不分区。要将表存储引擎更改为InnoDB，请执行以下语句：

      ALTER TABLE table_name ENGINE = INNODB;

      有关将MyISAM表转换为的信息InnoDB，请参见“将表从MyISAM转换为InnoDB”。

      要使分区表成为非分区表，请执行以下语句：

      ALTER TABLE table_name REMOVE PARTITIONING;
    3. 在MySQL 8.0中可能保留了一些以前未保留的关键字。请参见“关键字和保留字”。这可能导致以前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引号。请参见“模式对象名称”。

    4. MySQL 5.7 mysql系统数据库中的表不得与MySQL 8.0数据字典使用的表同名。要使用这些名称标识表，请执行以下查询：

      SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE LOWER(TABLE_SCHEMA) = 'mysql'
nd LOWER(TABLE_NAME) IN
(
'catalogs',
'character_sets',
'check_constraints',
'collations',
'column_statistics',
'column_type_elements',
'columns',
'dd_properties',
'events',
'foreign_key_column_usage',
'foreign_keys',
'index_column_usage',
'index_partitions',
'index_stats',
'indexes',
'parameter_type_elements',
'parameters',
'resource_groups',
'routines',
'schemata',
'st_spatial_reference_systems',
'table_partition_values',
'table_partitions',
'table_stats',
'tables',
'tablespace_files',
'tablespaces',
'triggers',
'view_routine_usage',
'view_table_usage'
);

      查询报告的任何表都必须删除或重命名（使用RENAME TABLE）。这也可能需要更改使用受影响表的应用程序。

    5. 不得有外键约束名称超过64个字符的表。使用此查询来标识约束名称太长的表：

      SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME IN
(SELECT LEFT(SUBSTR(ID,INSTR(ID,'/')	+1),
INSTR(SUBSTR(ID,INSTR(ID,'/')	+1),'_ibfk_')-1)
FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN
WHERE LENGTH(SUBSTR(ID,INSTR(ID,'/')	+1))
>64);

      对于约束名称超过64个字符的表，请删除该约束并将其添加回不超过64个字符的约束名称（请使用ALTER TABLE）。

    6. 您的sql_mode系统变量设置中不得定义过时的SQL模式。尝试使用过时的SQL模式将导致MySQL 8.0的启动失败。使用过时的SQL模式的应用程序也应该进行修改以避免它们。有关在MySQL 8.0中删除的SQL模式的信息，请参阅服务器更改。
    7. 不得有明确定义的列名超过64个字符的视图（MySQL 5.7允许使用列名最大为255个字符的视图）。为避免升级错误，应在升级之前更改此类视图。当前，识别列名称超过64个字符的视图的唯一方法是使用来检查视图定义SHOW CREATE VIEW。您也可以通过查询INFORMATION_SCHEMA.VIEWS表来检查视图定义。
    8. 表或存储过程中不得包含单个ENUM或SET列元素超过255个字符或1020个字节的长度。在MySQL 8.0之前，ENUM或SET列元素的最大组合长度为64K。在MySQL 8.0中，单个ENUM或SET列元素的最大字符长度为255个字符，最大字节长度为1020个字节。（1020字节限制支持多字节字符集）。在升级到MySQL 8.0之前，请修改超出新限制的任何元素ENUM或SET列元素。否则，将导致升级失败并显示错误。

    9. 升级到MySQL 8.0.13或更高版本之前，共享InnoDB表空间中不得存在任何表分区，共享表空间应包括系统表空间和常规表空间。通过查询来标识共享表空间中的表分区INFORMATION_SCHEMA：

      如果从MySQL 5.7升级，请运行以下查询：

      SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES 
WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';

      如果从早期的MySQL 8.0版本升级，请运行以下查询：

      SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLES 
WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';

      使用以下命令将表分区从共享表空间移至每个表文件表空间ALTER TABLE ... REORGANIZE PARTITION：

      ALTER TABLE table_name REORGANIZE PARTITION partition_name 
INTO (partition_definition TABLESPACE=innodb_file_per_table);
    10. MySQL 8.0.12或更低版本中不得有使用子句ASC或DESC限定符的查询和存储程序定义GROUP BY。否则，升级到MySQL 8.0.13或更高版本可能会失败，可能会复制到MySQL 8.0.13或更高版本的从属服务器。有关更多详细信息，请参见 SQL更改。

    11. 您的MySQL 5.7安装不得使用MySQL 8.0不支持的功能。此处的任何更改都必须是特定于安装的，但以下示例说明了要查找的内容：

      一些服务器启动选项和系统变量已在MySQL 8.0中删除。请参见在MySQL 8.0中删除的功能和“在MySQL 8.0中添加，不建议使用或删除的服务器和状态变量和选项”。如果使用其中任何一种，则升级需要更改配置。

      示例：由于数据字典提供了有关数据库对象的信息，因此服务器不再检查数据目录中的目录名称以查找数据库。因此，该--ignore-db-dir选项是多余的，已被删除。要解决此问题，请--ignore-db-dir从启动配置中删除所有实例。另外，在升级到MySQL 8.0之前，请删除或移动命名的数据目录子目录。（或者，让8.0服务器将这些目录作为数据库添加到数据字典中，然后使用删除每个数据库DROP DATABASE。）

    12. 如果打算lower_case_table_names在升级时将设置更改为1，请在升级前确保模式和表名均为小写。否则，由于架构或表名字母大小写不匹配，可能会发生故障。您可以使用以下查询来检查包含大写字符的架构和表名称：

      mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME != LOWER(TABLE_NAME) AND TABLE_TYPE = 'BASE TABLE';
mysql> SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME != LOWER(SCHEMA_NAME);

      从MySQL 8.0.19开始，如果lower_case_table_names=1，升级过程将检查表和架构名称，以确保所有字符均小写。如果发现表或架构名称包含大写字符，则升级过程将失败并显示错误。

      注意

      lower_case_table_names不建议在升级时更改设置。

    如果由于上述任何问题升级到MySQL 8.0失败，则服务器会将所有更改都还原到数据目录。在这种情况下，请删除所有重做日志文件，然后在现有数据目录上重新启动MySQL 5.7服务器以解决错误。重做日志文件（ib_logfile*）默认位于MySQL数据目录中。修复错误之后，请执行缓慢关机（通过设置innodb_fast_shutdown=0），然后再次尝试升级。

    上篇：使用Perl安装mySQL

    下篇：在Unix / Linux上升级MySQL