10bet网址
MySQL 8.0参考手册
相关的文档10bet官方网站 本手册下载 本手册节选

2.11.4 MySQL 8.0的变化

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

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

数据字典的变化

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_passwordcaching_sha2_password

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

    改变用户用户与caching_sha2_password相同密码”;
  • libmysqlclient图书馆对待caching_sha2_password作为默认的认证插件而不是mysql_native_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连接到配置的MySQL 8.0服务器可能有问题caching_sha2_password作为默认的身份验证插件,即使使用不认证的帐户caching_sha2_password.出现此问题是因为服务器向客户端指定了其默认身份验证插件的名称。如果一个客户端或连接器基于一个客户端/服务器协议实现,而该协议不能很好地处理一个无法识别的默认身份验证插件,它可能会失败,出现以下错误之一:

    认证插件“caching_sha2_password”不支持
    dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password. txt)无法加载鉴权插件caching_sha2_password。因此,2):图像未找到
    mysqli_connect():服务器请求的身份验证方法未知的客户端[caching_sha2_password]

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

  • 使用帐户进行身份验证的客户端caching_sha2_password必须使用安全连接(使用TCP和TLS/SSL凭据、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选择。

libmysqlclientMySQL 8.0之前版本的客户端库能够连接到MySQL 8.0服务器(除了身份验证帐户caching_sha2_password).这意味着8.0之前的客户端基于libmysqlclient应该也能连接。例子:

  • 标准的MySQL客户端,例如mysql而且mysqladminlibmysqlclient的。

  • Perl DBI的DBD::mysql驱动程序是libmysqlclient的。

  • MySQL Connector/Python有一个C Extension模块libmysqlclient的。要使用它,请包含use_pure = False选项在连接时。

当现有的MySQL 8.0安装升级到MySQL 8.0.4或更高版本时,有些更老libmysqlclient的客户可能会自动如果它们是动态链接的,则进行升级,因为它们使用升级所安装的新客户端库。例如,如果Perl DBI的DBD::mysql驱动程序使用动态链接,它可以使用libmysqlclient在升级到MySQL 8.0.4或更高版本后,会有这样的结果:

  • 在升级之前,使用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.(连接器/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连接器/Python脚本可以指定auth_plugin连接选项。(或者,使用连接器/Python C扩展,它能够连接到MySQL 8.0服务器而不需要auth_plugin)。

caching_sha2_password兼容的客户端和连接器

是否有已更新要了解的可用客户机或连接器caching_sha2_password当连接到配置的MySQL 8.0服务器时,使用它是确保兼容性的最佳方法caching_sha2_password作为默认的身份验证插件。

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

  • libmysqlclientMySQL 8.0(8.0.4或更高版本)的客户端库。标准的MySQL客户端,例如mysql而且mysqladminlibmysqlclient基于,所以它们也是兼容的。

  • libmysqlclientMySQL 5.7(5.7.23或更高版本)的客户端库。标准的MySQL客户端,例如mysql而且mysqladminlibmysqlclient基于,所以它们也是兼容的。

  • 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,身份验证插件现有帐户保持不变,包括用于“根”@“localhost”管理帐户。

对于新的MySQL 8.0安装,在初始化数据目录时(使用下面的说明)第2.10.1节“初始化数据目录”),“根”@“localhost”创建帐户,该帐户使用caching_sha2_password默认情况下。因此,要在数据目录初始化之后连接到服务器,您必须使用支持的客户机或连接器caching_sha2_password.如果你能做到这一点,但更喜欢账户使用mysql_native_password安装之后,安装MySQL并像平常一样初始化data目录。然后以和使用改变用户修改账号鉴权插件和密码的方法如下:

使用mysql_native_password修改root用户密码密码”;

如果您使用的客户机或连接器还不支持caching_sha2_password方法关联的修改后的数据目录初始化过程账户mysql_native_password一旦创建了帐户。要做到这一点,可以使用以下任何一种技巧:

caching_sha2_password和复制

在所有服务器都已升级到MySQL 8.0.4或更高版本的复制场景中,到源服务器的复制连接可以使用身份验证帐户caching_sha2_password.对于这样的连接,同样的要求适用于使用与进行身份验证的帐户的其他客户端caching_sha2_password:使用安全连接或基于rsa的密码交换。

连接到caching_sha2_password源/副本复制帐号:

  • 使用以下任何一种方法改变主选项:

    Master_ssl = 1 get_master_public_key = 1RSA公钥文件路径
  • 另外,如果在服务器启动时提供了所需的密钥,则可以使用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 = 'RSA公钥文件路径”;
  • 另外,如果在服务器启动时提供了所需的密钥,则可以使用RSA公钥相关选项。

配置更改

  • 不兼容的更改: MySQL存储引擎现在负责提供自己的分区处理程序,MySQL服务器不再提供通用的分区支持。InnoDB而且NDB是唯一提供MySQL 8.0支持的本地分区处理程序的存储引擎。必须修改使用任何其他存储引擎的分区表,以便将其转换为InnoDBNDB,或删除其分区-之前升级服务器,否则之后无法使用。

    有关转换的信息MyISAMInnoDB,请参阅第15.6.1.5节“表从MyISAM转换到InnoDB”

    如果表创建语句会导致使用不支持这种支持的存储引擎生成分区表,则会失败,并出现错误(ER_CHECK_NOT_IMPLEMENTED)。如果您从MySQL 5.7(或更早版本)中创建的转储文件中导入数据库, mysqldump进入MySQL 8.0服务器,您必须确保任何创建分区表的语句不会同时指定不支持的存储引擎,要么删除对分区的任何引用,要么将存储引擎指定为InnoDB或者允许它被设置为InnoDB默认情况下。

    请注意

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

    看到第24.6.2节,“与存储引擎相关的分区限制”,以查询更多资料。

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

  • 重要的变化:默认字符集已从latin1utf8mb4.受影响的系统变量有:

    因此,新对象的默认字符集和排序规则与以前不同,除非明确指定字符集和排序规则。这包括数据库和其中的对象,如表、视图和存储程序。假设使用了前面的默认值,那么保留它们的一种方法是在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中,与帐户管理相关的几个已被弃用的特性已被删除,例如使用格兰特语句来修改用户帐户的非特权特征NO_AUTO_CREATE_USERSQL模式下,密码()功能,old_passwords系统变量。

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

    为避免在MySQL 8.0上启动失败,请删除NO_AUTO_CREATE_USERsql_modeMySQL选项文件中的系统变量设置。

    的转储文件正在加载NO_AUTO_CREATE_USER将存储程序定义中的SQL模式导入MySQL 8.0服务器将导致失败。从MySQL 5.7.24和MySQL 8.0.13开始,, mysqldump删除NO_AUTO_CREATE_USER从存储程序定义。的较早版本创建的文件, mysqldump的实例必须手动修改才能删除NO_AUTO_CREATE_USER

  • 在MySQL 8.0.11中,这些已弃用的兼容SQL模式被移除:DB2MAXDB该软件MYSQL323MYSQL40甲骨文POSTGRESQLNO_FIELD_OPTIONSNO_KEY_OPTIONSNO_TABLE_OPTIONS.他们不能再被分配到sql_mode的允许值, mysqldump——兼容选择。

    删除MAXDB意味着时间戳数据类型创建表ALTER TABLE不再被视为DATETIME

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

  • 从MySQL 8.0.3开始,空间数据类型允许使用SRID属性,显式指示存储在列中的值的空间参考系统(SRS)。看到第11.4.1节“空间数据类型”

    具有显式的空间列SRID属性是SRID-restricted:列只接受带有该ID的值,并且空间列上的索引将由优化器使用。优化器会忽略空间号空间列上的索引SRID属性。看到第8.3.3节“空间索引优化”.如果您希望优化器考虑空间不受srid限制的空间列上的索引,每一个这样的列都应该修改:

    • 验证列中的所有值是否具有相同的SRID。确定几何列中包含的sridcol_name,使用以下查询:

      选择不同的ST_SRID (col_name)tbl_name

      如果查询返回多个行,则列包含多个srid。在这种情况下,修改它的内容,使所有值具有相同的SRID。

    • 重新定义列,使列具有显式SRID属性。

    • 重新创建空间索引。

  • MySQL 8.0.0中删除了几个空间函数,原因是空间函数名称空间的更改实现了一个ST_执行精确操作的函数的前缀MBR执行基于最小边界矩形的操作的函数的前缀。在生成的列定义中使用删除的空间函数可能导致升级失败。在升级之前,运行mysqlcheck——check-upgrade对于删除的空间函数,用它们替换任何您找到的空间函数ST_MBR命名的替代品。有关已删除空间函数的列表,请参见MySQL 8.0删除功能

  • BACKUP_ADMIN权限自动授予给具有重新加载当执行MySQL 8.0.3或更高版本的本地升级时。

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

    • 设置@@SESSION.binlog_format如果会话有任何打开的临时表,则不能使用。

    • 设置@@global.binlog_format而且设置@@persist.binlog_format如果复制区域通道中有打开的临时表,则不能使用此功能。设置@@persist_only.binlog_format如果复制通道有打开的临时表,则允许使用坚持PERSIST_ONLY不修改运行时全局系统变量值。

    • 设置@@global.binlog_format而且设置@@persist.binlog_format如果有复制区域通道应用程序正在运行,则不能使用。这是因为只有当复制区域通道的应用程序重新启动时,更改才会在复制区域通道上生效,此时复制区域通道可能已经打开了临时表。这种行为比以前更加严格。设置@@persist_only.binlog_format如果任何复制区域通道应用程序正在运行,则允许。

InnoDB的变化

  • INFORMATION_SCHEMA的观点的基础上InnoDB系统表被数据字典表上的内部系统视图所取代。影响InnoDBINFORMATION_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或更高版本后,更新以前引用的任何脚本InnoDBINFORMATION_SCHEMA视图名称。

  • zlib库与MySQL绑定的版本从1.2.3版本提升到1.2.11版本。

    zlibcompressBound ()函数在zlib 1.2.11中返回的压缩给定字节长度所需缓冲区大小的估计值比在zlib 1.2.3中略高。的compressBound ()函数由InnoDB确定在创建压缩时允许的最大行大小的函数InnoDB表或在压缩中插入和更新行InnoDB表。作为一个结果,创建表……ROW_FORMAT =压缩插入,更新在早期版本中,行大小非常接近最大行大小的操作现在可能会失败。要避免这个问题,请进行测试创建表语句压缩InnoDB在升级之前在MySQL 8.0测试实例上安装一个具有大行的表。

  • 随着的介绍——innodb-directories特性时,每个表一个文件的位置和使用绝对路径创建的一般表空间文件或在数据目录之外的位置创建的一般表空间文件的位置应该添加到innodb_directories参数值。否则,InnoDB在恢复期间无法定位这些文件。查询表空间文件的位置信息INFORMATION_SCHEMA。文件表:

    在“信息模式”中选择“表空间名称”和“文件名称”。文件\ G
  • 撤消日志不能再驻留在系统表空间中。在MySQL 8.0中,undo日志默认位于两个undo表空间中。有关更多信息,请参见第15.6.3.4节“撤消表空间”

    当从MySQL 5.7升级到MySQL 8.0时,MySQL 5.7实例中存在的所有undo表空间都会被删除,并被两个新的默认undo表空间所取代。属性定义的位置创建缺省undo表空间innodb_undo_directory变量。如果innodb_undo_directory变量未定义,则在数据目录中创建undo表空间。从MySQL 5.7升级到MySQL 8.0需要一个缓慢的关闭过程,以确保MySQL 5.7实例中的undo表空间为空,允许它们被安全删除。

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

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

    创建表空间ts1添加数据文件ts1。炎症性肠病的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.14、8.0.15或8.0.16升级到MySQL 8.0.17的区分大小写的文件系统,在将二进制文件或包升级到MySQL 8.0.17后启动服务器时,如果存在分区表,则会失败,出现以下错误lower_case_table_names = 1

    从服务器版本升级version_number在区分大小写的文件系统上使用分区表和lower_case_table_names == 1可能会导致问题,因此禁止使用。要升级,请使用命令行选项'upgrade=FORCE'重新启动新的服务器版本。升级完成后,请执行'RENAME TABLE 'part_table_namenew_table_name;重命名表new_table_namepart_table_name'为每个分区表。有关进一步信息,请参阅文档。10bet官方网站

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

    1. 使用以下命令重新启动服务器——升级=力强制升级操作继续进行。

    2. 用小写分区名分隔符标识分区表文件名(# #页# sp #):

      mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA文件WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
    3. 对于标识的每个文件,使用临时名称重命名关联的表,然后将表重命名为其原始名称。

      mysql >重命名表table_nametemporary_table_name;mysql >重命名表temporary_table_nametable_name
    4. 验证不存在分区表文件名、小写分区名分隔符(应该返回一个空结果集)。

      mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA文件WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; Empty set (0.00 sec)
    5. 运行分析表中的优化器统计信息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.17lower_case_table_names = 1.试图这样做的结果是表缺少表空间错误。

  • MySQL在为表分区构造表空间名和文件名时使用分隔符字符串。一个# p #分隔符字符串位于分区名称前面# sp #分隔符字符串位于子分区名称前面,如下所示:

    schema_nametable_name# p #partition_name# sp #subpartition_nametable_name# p #partition_name# sp #subpartition_name.ibd

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

    此外,根据用户指定的分区或子分区名称(可以用大写或小写指定)生成的分区表空间名称和文件名现在都是用小写生成(并在内部存储),而不管lower_case_table_names设置以确保不区分大小写。例如,如果用这个名称创建一个表分区PART_1,生成的表空间名称和文件名为小写:

    schema_nametable_name# p #part_1table_name# p #part_1.ibd

    在升级过程中,MySQL会根据需要进行检查和修改:

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

    • 分区数据字典中的元数据,以解决以前的错误修复程序引入的相关问题。

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

    在表空间导入操作期间,如果需要,将检查和修改磁盘上的分区表空间文件名,以确保小写分隔符和分区名称。

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

SQL的变化

  • 不兼容的更改:截至MySQL 8.0.13,已弃用ASCDESC限定符为集团条款已被删除。以前依赖的查询集团排序可能会产生不同于以前MySQL版本的结果。要生成给定的排序顺序,请提供命令条款。

    查询和存储程序定义从MySQL 8.0.12或更低使用ASCDESC限定符为集团条款应该修改。否则,升级到MySQL 8.0.13或更高版本可能会失败,复制到MySQL 8.0.13或更高版本的副本服务器也可能会失败。

  • MySQL 8.0中可能保留了MySQL 5.7中没有保留的一些关键字。看到第9.3节“关键词和保留词”.这可能导致以前用作标识符的单词变成非法的。要修复受影响的语句,请使用标识符引号。看到第9.2节“模式对象名称”

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

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

    的一致性InnoDBNDB基于MySQL 8.0.16或更高版本的版本使用生成的约束名约束象征子句未指定,或约束关键字不带参数象征NDB基于MySQL 5.7的版本和更早的MySQL 8.0版本使用外键index_name价值。

    上面描述的更改可能会对依赖于前面外键约束命名行为的应用程序引入不兼容性。

改变服务器默认值

MySQL 8.0提供了改进的默认值,旨在提供最好的开箱即用的体验。这些变化是由技术进步所驱动的(机器有更多的cpu,使用ssd等等),更多的数据被存储,MySQL也在发展(InnoDB, Group Replication, AdminAPI)等等。下表总结了为为大多数用户提供最佳MySQL体验而更改的默认值。

选项/参数 旧的违约 新的默认
服务器的变化
character_set_server latin1 utf8mb4
collation_server latin1_swedish_ci utf8mb4_0900_ai_ci
explicit_defaults_for_timestamp
optimizer_trace_max_mem_size 16 kb 1 mb
validate_password_check_user_name
back_log back_log = 50 + (max_connections / 5) -1 (autosize)更改为:back_log = max_connections
max_allowed_packet 4194304 (4 mb) 67108864 (64 mb)
max_error_count 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), unbuffered (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 / % =”
performance-schema-instrument =“内存/ % =统计”
performance-schema-consumer-events-transactions-current =对
performance-schema-consumer-events-transactions-history =对
performance-schema-instrument = '事务% = '
复制的变化
log_bin
server_id 0 1
log-slave-updates
expire_logs_days 0 30.
master-info-repository 文件 表格
relay-log-info-repository 文件 表格
transaction-write-set-extraction XXHASH64
slave_rows_search_algorithms INDEX_SCAN, TABLE_SCAN INDEX_SCAN, HASH_SCAN
slave_pending_jobs_size_max 16米 128米
gtid_executed_compression_period 1000 0
组复制更改
group_replication_autorejoin_tries 0 3.
group_replication_exit_state_action ABORT_SERVER READ_ONLY
group_replication_member_expel_timeout 0 5

有关已添加的选项或变量的详细信息,请参见MySQL 8.0的选项/变量更改,在MySQL服务器版本参考

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

服务器默认值

  • 的默认值character_set_server系统变量和命令行选项——character-set-serverlatin1utf8mb4.这是服务器的默认字符集。目前,UTF8MB4是web的主要字符编码,这一变化使绝大多数MySQL用户的生活更容易。从5.7升级到8.0不会更改任何现有数据库对象的字符集。但除非你明确说明character_set_server返回以前的默认值或显式设置字符集,然后默认使用新模式、表或列utf8mb4.我们建议你搬到utf8mb4只要有可能。

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

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

  • 的默认值optimizer_trace_max_mem_size系统变量从16 kb1 mb.旧的默认值导致优化器跟踪对于任何非普通查询都被截断。此更改确保优化器对大多数查询进行有用的跟踪。

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

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

  • 的默认值max_allowed_packet系统变量从4194304(4米)67108864(64米)。这个较大的默认值的主要优点是接收到关于插入或查询大于的错误的可能性更小max_allowed_packet.它应该和最大的一样大第11.3.4节“BLOB和TEXT类型”你想用。若要恢复到以前的行为,请设置max_allowed_packet = 4194304

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

  • 的默认值event_scheduler系统变量从.换句话说,事件调度器在默认情况下是启用的。这为SYS中的新特性提供了支持,例如“杀死空闲事务”。

  • 的默认值table_open_cache系统变量从20004000.这是一个小的更改,它增加了表访问上的会话并发性。

  • 的默认值log_error_verbosity系统变量从3.(笔记)2(警告)。目的是在默认情况下减少MySQL 8.0错误日志的详细信息。

InnoDB违约

  • 不兼容的更改的默认值innodb_undo_tablespaces系统变量从02.配置InnoDB使用的undo表空间的数量。的最小值innodb_undo_tablespaces的值为2,回滚段不能再在系统表空间中创建。因此,在这种情况下,您无法恢复到5.7行为。此更改的目的是能够自动截断Undo日志(见下一项),回收(偶尔的)长事务所使用的磁盘空间,例如, mysqldump

  • 的默认值innodb_undo_log_truncate系统变量从.在启用时,撤销超过由定义的阈值的表空间innodb_max_undo_log_size标记为截断。只有undo表空间可以被截断。不支持截断系统表空间中的undo日志。从5.7升级到8.0会自动将系统转换为使用undo表空间,在8.0中不支持使用system表空间。

  • 的默认值innodb_flush_method系统变量从fsync在类unix系统和从无缓冲的在Windows系统。这更多的是一个术语和选项清理,没有任何有形的影响。对于Unix,这只是一个文档更改,就像默认的那样10bet官方网站fsync同样在5.7(默认的意思fsync).同样在Windows上,innodb_flush_method默认的的意思async_unbuffered,默认被替换无缓冲的在8.0中,其中与现有的默认值相结合innodb_use_native_aio =对有同样的效果。

  • 不兼容的更改的默认值innodb_autoinc_lock_mode系统变量从1(连续)2(交叉)。将交错锁定模式作为默认设置的更改反映了默认复制类型从基于语句到基于行复制的更改,这发生在MySQL 5.7中。Statement-based复制需要连续自动增量锁定模式,以确保对给定的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当10%的缓冲池包含修改的(“脏”)页面时,InnoDB会增加它的刷新活动。此更改的目的是稍微降低峰值吞吐量,以换取更一致的性能。

  • 的默认值innodb_max_dirty_pages_pct系统变量从75(%)90(%)。这种变化与to的变化相结合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 / % =”.这有助于在SYS中添加面向MDL的视图。

  • 默认情况下,内存检测是打开的。的已编译默认值performance-schema-instrument =“内存/ % =统计”.这很重要,因为如果在服务器启动后启用了插装,则会计是不正确的,您可能会因为错过分配而获得负余额,但却捕获了空闲。

  • 默认情况下,事务检测是打开的。的已编译默认值performance-schema-consumer-events-transactions-current =对performance-schema-consumer-events-transactions-history =对,performance-schema-instrument = '事务% = '

复制默认值

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

  • 的默认值server_id系统变量从01(结合到log_bin =对).可以使用这个默认ID启动服务器,但实际上必须设置服务器id根据正在部署的复制基础设施,避免有重复的服务器id。

  • 的默认值log-slave-updates系统变量从.这将导致副本将复制的事件记录到它自己的二进制日志中。此选项是Group Replication所必需的,并且还确保了在各种复制链设置中的正确行为,这已成为当今的规范。

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

  • 的默认值master_info_repository而且relay_log_info_repository系统变量从文件表格.因此在8.0中,复制元数据默认存储在InnoDB中。这增加了尝试在默认情况下实现崩溃安全复制的可靠性。

  • 的默认值transaction-write-set-extraction系统变量从XXHASH64.此更改默认启用事务写集。通过使用事务写集,源必须稍微多做一些工作来生成写集,但结果有助于冲突检测。这是Group Replication的要求,新的默认值使得在源上启用二进制日志写集并行化可以加快复制。

  • 的默认值slave_rows_search_algorithms系统变量从INDEX_SCAN, TABLE_SCANINDEX_SCAN, HASH_SCAN.这种更改减少了复制应用程序将更改应用到没有主键的表时必须进行的表扫描次数,从而加快了基于行的复制。

  • 的默认值slave_pending_jobs_size_max系统变量从16米128米.此更改增加了可用于多线程副本的内存量。

  • 的默认值gtid_executed_compression_period系统变量从10000.的压缩mysql.gtid_executed表只在需要时隐式出现。

组复制默认值

大多数默认值都非常适合开发和生产环境。有一个例外,我们决定保持新的选项称为innodb_dedicated_server设置为尽管我们建议这样做在生产环境中。默认的原因它会导致共享环境(如开发人员笔记本电脑)变得不可用吗所有它能找到的记忆。

对于生产环境,我们建议设置innodb_dedicated_server.当设置为以下InnoDB变量(如果没有显式指定)是根据可用内存自动伸缩的通过innodb_buffer_pool_sizeinnodb_log_file_size,innodb_flush_method.看到第15.8.12节“为专用MySQL服务器启用自动配置”

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

在MySQL 8.0中有一个性能模式variables_info表,它显示了每个系统变量最近设置的源及其值范围。因此,在8.0中,您可以通过SQL访问了解配置变量及其值的所有信息。看到第27.12.14.2节“性能模式变量_info表”