# 2.11.4 MySQL 8.0 的变化

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

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

# 数据字典更改

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

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

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

# 缓存_沙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]
    

    有关编写连接器以优雅地处理来自服务器的未知默认身份验证插件请求的信息,请参阅身份验证插件连接器 - 编写注意事项.

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

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

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

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

  • 标准 MySQL 客户端,例如mysqlmysql管理员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帐户也是如此。

    然而,出现上述结果是因为libmysqlclient8.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.0mysql_本机_密码作为默认的身份验证插件,如前所述。

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

  • 一些MySQL客户端支持--默认身份验证选项(标准MySQL客户端,例如mysqlmysqladmin支持此选项,但可以在没有此选项的情况下成功连接到8.0服务器。然而,其他客户可能支持类似的选择。如果是的话,值得一试。)

  • 使用libmysqlclientC API可以调用mysql_选项() (opens new window)MYSQL\u默认值\u身份验证选项

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

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

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

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

  • 这个libmysqlclientMySQL 8.0(8.0.4或更高版本)中的客户端库。标准MySQL客户端,例如mysqlmysqladminlibmysqlclient-基于,所以它们也是兼容的。

  • 这个libmysqlclientMySQL 5.7(5.7.23或更高版本)中的客户端库。标准MySQL客户端,例如mysqlmysqladminlibmysqlclient-基于,所以它们也是兼容的。

  • 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节,“初始化数据目录”),这个“根”@“本地主机”帐户被创建,并且该帐户使用缓存_sha2_密码默认情况下。因此,要在数据目录初始化后连接到服务器,必须使用支持缓存_sha2_密码.如果你能做到但更喜欢帐户使用mysql_本机_密码安装完成后,安装MySQL并像往常一样初始化数据目录。然后连接到服务器作为使用改变用户更改帐户身份验证插件和密码的步骤如下:

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

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

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

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

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

  • 使用以下任何一项将主机更改为选项:

    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服务器不再提供通用分区支持。InnoDBNDB是唯一提供MySQL 8.0支持的本机分区处理程序的存储引擎。必须对使用任何其他存储引擎的分区表进行更改,以将其转换为InnoDBNDB,或删除其分区-之前升级服务器,否则以后无法使用。

    有关转换的信息米萨姆桌子InnoDB看见第15.6.1.5节,“将表格从MyISAM转换为InnoDB”.

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

    笔记

    程序见第2.11.5节,“为升级准备安装”,描述如何识别升级到MySQL 8.0之前必须更改的分区表。

    看见第24.6.2节,“与存储引擎相关的分区限制”,以获取更多信息。

  • 不相容的变化:多个服务器错误代码未使用且已被删除(有关列表,请参阅MySQL 8.0中删除的功能)。应更新专门针对其中任何一个进行测试的应用程序。

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

    • 的默认值字符集服务器字符集数据库系统变量已从拉丁语1utf8mb4.

    • 的默认值整理服务器整理数据库系统变量已从拉丁语瑞典语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开始,禁止使用小写字母表名称与服务器初始化时使用的设置不同的设置。这种限制是必要的,因为各种数据字典表字段使用的排序规则都基于小写字母表名称初始化服务器时定义的设置,以及使用不同的设置重新启动服务器会导致标识符排序和比较方式不一致。

# 服务器更改

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

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

    为了避免MySQL 8.0上的启动失败,请删除无自动创建用户从…起sql_模式MySQL选项文件中的系统变量设置。

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

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

    移除MAXDB意味着时间戳的数据类型创建表格改变桌子不再被视为约会时间.

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

  • 从MySQL 8.0.3开始,空间数据类型允许SRID属性,以明确指示存储在列中的值的空间参考系(SRS)。看见第11.4.1节,“空间数据类型”.

    带有显式SRID属性受SRID限制:列只接受具有该ID的值,并且空间的列上的索引将由优化器使用。优化器忽略了空间的空间列上没有索引的索引SRID属性看见第8.3.3节,“空间索引优化”如果希望优化器考虑空间的不受SRID限制的空间列上的索引,应修改每个此类列:

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

      SELECT DISTINCT ST_SRID(col_name) FROM tbl_name;
      

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

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

    • 重现空间的指数

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

  • 这个备份管理权限将自动授予具有重新加载执行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中,为内部存储引擎需要会话变量管理系统变量管理特权

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

# InnoDB的变化

  • 信息模式基于InnoDB系统表被数据字典表上的内部系统视图替换。影响InnoDB 信息模式视图被重命名为:

    表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 信息模式查看名称。

  • 这个zlib图书馆 (opens new window)与MySQL捆绑的版本从版本1.2.3提升到版本1.2.11。

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

  • 随着--innodb目录功能,每个表的文件位置和使用绝对路径或在数据目录之外的位置创建的常规表空间文件应添加到innodb_目录参数值。否则InnoDB在恢复期间无法找到这些文件。要查看表空间文件位置,请查询信息模式。文件夹表:

    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实例中存在的所有undo表空间都将被删除,并替换为两个新的默认undo表空间。默认的撤消表空间是在innodb_undo_目录变量如果innodb_undo_目录变量未定义,则在数据目录中创建撤消表空间。从MySQL 5.7升级到MySQL 8.0需要缓慢关闭,以确保MySQL 5.7实例中的undo表空间为空,从而允许安全地删除它们。

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

  • 不相容的变化:从MySQL 8.0.17开始创建表空间。。。添加数据文件子句不允许循环目录引用。例如,循环目录引用(/../)不允许在以下声明中使用:

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

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

    为了避免升级问题,请在升级到MySQL 8.0.17或更高版本之前,从表空间数据文件路径中删除所有循环目录引用。要检查表空间路径,请查询信息模式。INNODB_数据文件桌子

  • 由于MySQL 8.0.14中引入了一种回归,对于具有分区表和数据库的实例,从MySQL 5.7或MySQL 8.0.14之前的MySQL 8.0版本到MySQL 8.0.16的区分大小写文件系统的就地升级失败小写字母表名称=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后,如果存在分区表且小写字母表名称=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. 使用以下命令重新启动服务器:--升级=强制以强制升级操作继续。

    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. 分析表在每个重命名的表上更新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。尝试这样做会导致“表空间对于表丢失”错误。

  • 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设置以确保不区分大小写。例如,如果使用名称创建表分区第1部分,生成的表空间名和文件名都是小写的:

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

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

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

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

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

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

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

# 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 节,“关键字和保留字”.这可能导致以前用作标识符的单词变得非法。要修复受影响的语句,请使用标识符引用。看第 9.2 节,“架构对象名称”.

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

  • 不兼容的变化:在 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()案子()在 MySQL 8.0.22 中更改;系统变量值现在被处理为相同字符和排序规则的列值,而不是常量。使用这些函数和以前成功的系统变量的一些查询随后可能会因非法混合排序规则而被拒绝。在这种情况下,将系统变量转换为正确的字符集和排序规则。

  • 不兼容的变化:MySQL 8.0.28 修复了以前的 MySQL 8.0 版本中的一个问题,即转变()函数有时允许无效转换二进制非二进制字符集的值。应检查可能依赖此行为的应用程序,并在必要时在升级前进行修改。

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

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

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

      您还可以使用强制重建表更改表 *桌子* 力量, 反而。

    3. 升级 MySQL 软件。

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

# 更改了服务器默认值

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

选项/参数 旧默认 新默认值
服务器更改
character_set_server 拉丁语1 utf8mb4
collat​​ion_server 拉丁语1_瑞典_词 utf8mb4_0900_艾_词
显式默认值for_timestamp 离开
optimizer_trace_max_mem_size 16KB 1MB
validate_password_check_user_name 离开
back_log -1(自动调整大小)从:返回_对数 = 50 +(最大值_连接 / 5) -1(自动调整大小)更改为:返回_日志 = 最大值_连接
max_allowed_pa​​cket 4194304 (4MB) 67108864 (64MB)
最大错误计数 64 1024
event_scheduler 离开
table_open_cache 2000 4000
log_error_verbosity 3(注) 2(警告)
InnoDB 更改
innodb_undo_tablespaces 0 2
innodb_undo_log_truncate 离开
innodb_flush_method 空值 fsync (Unix),无缓冲 (Windows)
innodb_autoinc_lock_mode 1(连续) 2(交错)
innodb_flush_neighbors 1(启用) 0(禁用)
innodb_max_dirty_pages_pct_lwm 0 (%) 10 (%)
innodb_max_dirty_pages_pct 75 (%) 90 (%)
性能架构更改
performance-schema-instrument='等待/锁定/元数据/sql/%=ON' 离开
性能模式仪器='内存/%=计数' 离开 计数
性能-模式-消费者-事件-事务-当前=ON 离开
性能-模式-消费者-事件-交易-历史=开启 离开
性能模式工具='事务%=ON' 离开
复制更改
log_bin 离开
server_id 0 1
日志从更新 离开
expire_logs_days 0 30
主信息存储库 文件 桌子
中继日志信息存储库 文件 桌子
事务写集提取 离开 XXHASH64
slave_rows_search_algorithms 指数_扫描,表格_扫描 指数_扫描,哈希_扫描
slave_pending_jobs_size_max 16M 128M
gtid_executed_compression_period 1000 0
组复制更改
group_replication_autorejoin_tries 0 3
group_replication_exit_state_action 中止_服务器 读_只要
group_replication_member_expel_timeout 0 5

有关已添加的选项或变量的更多信息,请参阅MySQL 8.0 的选项/变量更改 (opens new window), 在里面MySQL 服务器版本参考.

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

服务器默认值

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

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

  • 的默认值显式默认值for_timestamp系统变量从离开(MySQL 遗留行为)到(SQL 标准行为)。这个选项最初是在 5.6 中引入的,并且是离开在 5.6 和 5.7 中。

  • 的默认值optimizer_trace_max_mem_size系统变量从16KB1MB.旧的默认设置会导致优化器跟踪被截断以用于任何重要的查询。此更改确保对大多数查询有用的优化器跟踪。

  • 的默认值validate_password_check_user_name系统变量从离开.这意味着当验证密码插件已启用,默认情况下它现在拒绝与当前会话用户名匹配的密码。

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

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

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

  • 的默认值事件调度程序系统变量已从在…上。换句话说,默认情况下启用事件计划程序。这是SYS中新功能的启用码,例如“杀死空闲事务”。

  • 的默认值表_打开_缓存系统变量已从20004000.这是一个小改动,它增加了表访问的会话并发性。

  • 的默认值日志错误详细系统变量已从3.(注)至2.(警告)。其目的是在默认情况下减少MySQL 8.0错误日志的详细程度。

InnoDB默认值

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

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

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

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

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

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

  • 的默认值innodb_max_dirty_pages_pct系统变量从75(%) 到90(%)。此更改与更改为innodb_max_dirty_pages_pct_lwm它们共同确保 InnoDB 的平滑刷新行为,避免刷新突发。要恢复到以前的行为,请设置innodb_max_dirty_pages_pct=75innodb_max_dirty_pages_pct_lwm=0.

性能架构默认值

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

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

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

复制默认值

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

  • 的默认值服务器id系统变量已从01.(结合对登录)。可以使用此默认ID启动服务器,但实际上必须设置服务器id根据正在部署的复制基础架构,以避免重复的服务器ID。

  • 的默认值日志从属更新系统变量已从在…上。这会导致复制副本将复制的事件记录到自己的二进制日志中。此选项对于组复制是必需的,并且还可以确保在各种复制链设置中的正确行为,这已成为当今的标准。

  • 的默认值过期_日志_天系统变量已从030.新的违约30原因mysqld定期清除超过30天的未使用二进制日志。此更改有助于防止在二进制日志上浪费过多的磁盘空间,而这些日志不再需要用于复制或恢复目的。旧价值观0禁用任何自动二进制日志清除。

  • 的默认值主信息存储库中继日志信息存储库系统变量从文件桌子。因此,在8.0中,复制元数据默认存储在InnoDB中。这提高了在默认情况下尝试实现崩溃安全复制的可靠性。

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

  • 的默认值从行搜索算法系统变量已从索引扫描,表格扫描索引扫描、哈希扫描。此更改通过减少复制应用程序将更改应用于没有主键的表所需的表扫描次数,加快了基于行的复制。

  • 的默认值从属\u待处理\u作业\u大小\u最大值系统变量已从16M128M。此更改增加了多线程副本可用的内存量。

  • 的默认值gtid_执行_压缩_周期系统变量已从10000.此更改可确保mysql。gtid_已执行表仅在需要时隐式出现。

组复制默认值

  • 的默认值组\u复制\u自动连接\u尝试从0更改为3,这意味着默认情况下启用自动重新加入。此系统变量指定成员在被驱逐或无法在被驱逐前联系到该组大多数成员时自动重新加入该组的尝试次数组\复制\无法访问\多数\超时已达到设定值。

  • 的默认值组\复制\退出\状态\操作中止服务器只读。这意味着当成员退出组时,例如在网络故障后,实例将变为只读,而不是关闭。

  • 的默认值组\复制\成员\驱逐\超时从0改为5,这意味着怀疑与该团体失去联系的成员在5秒检测期后5秒将被驱逐出境。

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

    对于生产环境,我们建议设置innodb_专用_服务器在…上.当设置为在…上以下InnoDB变量(如果没有明确指定)是基于可用内存自动调整的innodb_缓冲区_池_大小, innodb_日志_文件_大小innodb_flush_方法看见第15.8.12节,“为专用MySQL服务器启用自动配置”.

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

    MySQL 8.0具有性能模式变量信息表,其中显示了每个系统变量最近一次设置的来源及其值范围。这提供了对配置变量及其值的所有相关信息的SQL访问。