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 BY密码”;
  • libmysqlclient图书馆对待caching_sha2_password作为默认的身份验证插件而不是mysql_native_password

以下各节讨论的影响更突出的作用caching_sha2_password

caching_sha2_password兼容性问题及解决方案
重要的

如果你的MySQL安装必须提供8.0之前的客户端,并且在升级到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'
    无法加载认证插件caching_sha2_password: dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password)所以,2):图像没有找到
    mysqli_connect():客户端不知道服务器请求的认证方法

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

  • 使用的身份验证帐户的客户端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的帐户的连接,身份验证需要一个额外的往返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账户。

然而,出现上述结果是因为libmysqlclient在8.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.直到更新版本mysqlndPHP客户端连接MySQL 8.0的方式是重新配置服务器恢复到mysql_native_password作为默认的身份验证插件,如前所述。

如果客户端或连接器支持显式指定默认身份验证插件的选项,使用它来命名插件,而不是caching_sha2_password.例子:

  • 一些MySQL客户端支持——default-auth选择。(标准的MySQL客户端,如mysql而且mysqladmin支持这个选项,但是没有它也可以成功连接到8.0服务器。但是,其他客户机可能也支持类似的选项。如果是这样,值得一试。)

  • 使用libmysqlclientC API可以调用mysql_options ()函数与MYSQL_DEFAULT_AUTH选择。

  • MySQL连接器/Python脚本使用本地Python实现的客户端/服务器协议可以指定auth_plugin连接选项。(或者,使用Connector/Python C Extension,它能够连接到MySQL 8.0服务器,而不需要auth_plugin)。

caching_sha2_password-兼容的客户机和连接器

如果有客户端或连接器可用,并且已经更新以了解caching_sha2_password在连接MySQL 8.0服务器时,使用它是确保兼容性的最佳方法caching_sha2_password作为默认的认证插件。

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

  • libmysqlclient客户端库在MySQL 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

    不支持PDO_MySQL和ext/mysqli扩展caching_sha2_password.此外,在使用7.1.16之前的PHP版本和7.2.4之前的PHP版本时,它们无法连接default_authentication_plugin = caching_sha2_password即使caching_sha2_password是不习惯。

caching_sha2_password和root管理员帐号

对于升级到MySQL 8.0,认证插件现有的帐户保持不变,包括插件的“根”@“localhost”管理帐户。

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

ALTER USER 'root'@'localhost'密码”;

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

caching_sha2_password和复制

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

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

  • 使用下列任何一种改变主选项:

    get_master_public_key = 1 master_public_key_path ='RSA公钥文件的路径
  • 或者,如果在服务器启动时提供了所需的密钥,您可以使用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到8.0复制引用这些被删除特性的语句可能会导致复制失败。应用程序如果使用任何被删除的特性,应修改以避免它们,并在可能的情况下使用替代品,如MySQL 8.0中删除的特性

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

    加载转储文件,其中包含NO_AUTO_CREATE_USERMySQL 8.0服务器中存储的程序定义中的SQL模式会导致失败。对于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

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

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

    带有显式的空间列SRID属性受srid限制:列只接受带有该ID的值空间列上的索引将由优化器使用。优化器会忽略空间在空间列上不带no的索引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信息Schema视图

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

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

    从information_schema中选择tablespace_name, file_name。文件\ G
  • Undo日志将不再存在于系统表空间中。在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表空间,可以使用undo表空间来停用和删除它改变撤消表空间而且下降撤消表空间语法,分别升级后。MySQL 8.0版本系列的升级可能并不总是需要慢关机,这意味着现有的undo表空间可能包含undo日志。因此,升级过程不会删除现有的undo表空间。

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

    添加数据文件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 8.0.17从MySQL 5.7或MySQL 8.0升级到MySQL 8.0.14之前的版本,以正常运行。然而,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 #):

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

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

      从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.17在区分大小写的文件系统上是不支持的lower_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 #)和小写(如Linux)。# 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会根据需要进行检查和修改:

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

    • 在数据字典中划分元数据,以解决以前bug修复中引入的相关问题。

    • InnoDB以前的bug修复中引入的相关问题的统计数据。

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

  • 在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 5.7中没有保留的关键字在MySQL 8.0中可能会被保留。看到第9.3节,“关键词和保留词”.这可能会导致以前用作标识符的单词变得非法。要修复受影响的语句,请使用标识符引号。看到第9.2节,“模式对象名称”

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

  • 不兼容的更改:在MySQL 5.7中指定一个外键定义为一个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 -1(自动大小)改变:back_log = 50 + (max_connections / 5) -1(自动大小)更改为: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

有关已添加的选项或变量的详细信息,请参见选项/变量的变化mysqld8.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表空间的个数。在MySQL 8.0中,最小值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中不允许使用系统表空间。

  • 默认值innodb_flush_method系统变量由fsync在类unix系统上无缓冲的在Windows系统。这更多的是一种术语和选项清理,没有任何实际影响。对于Unix来说,这只是一个文档更改,就像默认的10bet官方网站那样fsync同样在5.7中(默认的意思fsync).同样在Windows上,innodb_flush_method默认的的意思async_unbuffered在5.7中,和被默认替换无缓冲的在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(%)。此更改与对的更改结合在一起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系统变量由.这将导致副本将复制的事件记录到自己的二进制日志中。此选项对于组复制是必需的,并且还确保各种复制链设置中的正确行为,这些设置已经成为今天的标准。

  • 默认值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节,“性能模式变量表”