2.11.4 MySQL 8.0中的更改

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

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

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

数据字典更改

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

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可能需要其他配置（请参见 第6.4.1.2节“缓存SHA-2可插拔身份验证”）。但是，默认情况下，MySQL 8.0中的客户端连接更喜欢使用TLS / SSL，因此已经符合该首选项的客户端可能不需要其他配置。

• 尚未更新了解的客户端和连接器caching_sha2_password 无法连接到进行身份验证的帐户，caching_sha2_password 因为它们无法识别此插件有效。（这是如何应用客户端/服务器身份验证插件兼容性要求的特定实例，如 身份验证插件客户端/服务器兼容性中所述。）要变通解决此问题，请libmysqlclient从MySQL 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。（需要Connector / J 8.0.9或更高版本才能连接到 caching_sha2_password帐户。）

使用客户端/服务器协议以外的实现的客户端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脚本可以指定 auth_plugin连接选项。（或者，使用Connector / Python C扩展程序，该扩展程序无需即可连接到MySQL 8.0服务器 auth_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，在初始化数据目录（使用 第2.10.1节“初始化数据目录”中的说明）时，将'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，请参见 第15.6.1.5节“将表从MyISAM转换为InnoDB”。

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

  注意

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

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

• 不兼容的更改：几个服务器错误代码未使用且已删除（有关列表，请参阅 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到引用这些已删除功能的语句的复制可能会导致复制失败。使用任何已删除功能的应用程序都应进行修改，以避免使用它们，并尽可能使用替代方法，如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 TABLEDATETIME

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

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

  具有显式SRID 属性的空间列受SRID限制：该列仅接受具有该ID的值，并且SPATIAL该列上的索引将由优化程序使用。优化器将忽略SPATIAL没有SRID属性的空间列上的索引。请参见 第8.3.3节“空间索引优化”。如果希望优化器考虑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系统表的视图被数据字典表上的内部系统视图替换。受影响的 InnoDB INFORMATION_SCHEMA视图已重命名：

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

  旧名称	新名字
  INNODB_SYS_COLUMNS	INNODB_COLUMNS
  INNODB_SYS_DATAFILES	INNODB_DATAFILES
  INNODB_SYS_FIELDS	INNODB_FIELDS
  INNODB_SYS_FOREIGN	INNODB_FOREIGN
  INNODB_SYS_FOREIGN_COLS	INNODB_FOREIGN_COLS
  INNODB_SYS_INDEXES	INNODB_INDEXES
  INNODB_SYS_TABLES	INNODB_TABLES
  INNODB_SYS_TABLESPACES	INNODB_TABLESPACES
  INNODB_SYS_TABLESTATS	INNODB_TABLESTATS
  INNODB_SYS_VIRTUAL	INNODB_VIRTUAL

  升级到MySQL 8.0.3或更高版本后，请更新所有引用先前InnoDB INFORMATION_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中，默认情况下，撤消日志位于两个撤消表空间中。有关更多信息，请参见 第15.6.3.4节“撤消表空间”。

  从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 'any_directory/../ts1.ibd';
  

  限制是一个例外，在Linux上，如果先前的目录是符号链接，则允许循环目录引用。例如，如果*any_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.17后启动服务器，则在区分大小写的文件系统上从MySQL 8.0.14、8.0.15或8.0.16到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 先前的错误修复所引入的相关问题的统计数据。

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

• 从MySQL 8.0.21开始，如果发现表空间数据文件位于未知目录中，则会在启动时或从MySQL 5.7升级时向错误日志中写入警告。已知的目录那些被定义的 datadir， innodb_data_home_dir和 innodb_directories 变量。要使目录已知，请将其添加到 innodb_directories设置中。使目录已知可确保在恢复期间可以找到数据文件。有关更多信息，请参见 崩溃恢复期间的表空间发现。

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中未保留。请参见 第9.3节“关键字和保留字”。这可能导致以前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引号。请参见 第9.2节“模式对象名称”。

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

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

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

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