在升级到MySQL 8.0之前,请检查本节描述的更改,以确定哪些更改适用于当前的MySQL安装和应用程序。执行任何推荐的操作。
更改标记为不兼容的更改与早期版本的MySQL不兼容,并可能需要您的注意在升级之前.我们的目标是避免这些更改,但有时它们对于纠正比版本间不兼容更糟糕的问题是必要的。如果适用于您的安装的升级问题涉及不兼容,请遵循描述中给出的说明。
MySQL Server 8.0合并了一个全局数据字典,其中包含事务表中关于数据库对象的信息。在以前的MySQL系列中,字典数据存储在元数据文件和非事务性系统表中。因此,在升级过程中,需要通过检查特定的前提条件来验证安装的升级准备情况。有关更多信息,请参见第2.11.5节,“为升级准备安装”.支持数据字典的服务器需要一些一般的操作差异;看到第14.7节,“数据字典使用差异”.
的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
可以使用改变用户
声明:改变用户用户使用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
选择。
的libmysqlclient
MySQL 8.0之前版本的客户端库能够连接到MySQL 8.0服务器(除了通过caching_sha2_password
).这意味着8.0之前的客户端基于libmysqlclient
也应该能够连接。例子:
标准的MySQL客户端,如mysql而且mysqladmin是
libmysqlclient
的。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
.直到更新版本mysqlnd
PHP客户端连接MySQL 8.0的方式是重新配置服务器恢复到mysql_native_password
作为默认的身份验证插件,如前所述。
如果客户端或连接器支持显式指定默认身份验证插件的选项,使用它来命名插件,而不是caching_sha2_password
.例子:
一些MySQL客户端支持
——default-auth
选择。(标准的MySQL客户端,如mysql而且mysqladmin支持这个选项,但是没有它也可以成功连接到8.0服务器。但是,其他客户机可能也支持类似的选项。如果是这样,值得一试。)使用
libmysqlclient
C 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而且mysqladmin是libmysqlclient
,所以它们也是兼容的。的
libmysqlclient
MySQL 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
.不支持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
只要创建好帐户。要做到这一点,可以使用以下任何一种技巧:
提供一个
——default-authentication-plugin = mysql_native_password
选择与——初始化
或——initialize-insecure
.集
default_authentication_plugin
来mysql_native_password
在选项文件中,并使用——defaults-file
选择与——初始化
或——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
源/副本复制的帐户:
使用下列任何一种
改变主
选项: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中唯一提供本地分区处理程序的存储引擎。必须更改使用任何其他存储引擎的分区表—或者将其转换为InnoDB
或NDB
,或者去掉它的分划之前对服务器进行升级,否则后续无法使用。有关转换
MyISAM
表InnoDB
,请参阅第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中删除的特性).应该更新专门针对它们进行测试的应用程序。
重要的变化:默认字符集已从
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中,一些与帐户管理相关的已弃用特性已被移除,例如使用
格兰特
语句修改用户帐户的非特权特征NO_AUTO_CREATE_USER
SQL模式下,密码()
功能,old_passwords
系统变量。从MySQL 5.7到8.0复制引用这些被删除特性的语句可能会导致复制失败。应用程序如果使用任何被删除的特性,应修改以避免它们,并在可能的情况下使用替代品,如MySQL 8.0中删除的特性.
为了避免在MySQL 8.0上启动失败,删除所有的实例
NO_AUTO_CREATE_USER
从sql_mode
MySQL选项文件中的系统变量设置。加载转储文件,其中包含
NO_AUTO_CREATE_USER
MySQL 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模式被移除:
DB2
,MAXDB
,该软件
,MYSQL323
,MYSQL40
,甲骨文
,POSTGRESQL
,NO_FIELD_OPTIONS
,NO_KEY_OPTIONS
,NO_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。确定几何列中包含的srid
col_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
如果正在运行任何复制通道应用程序,则允许。
INFORMATION_SCHEMA
的观点的基础上InnoDB
系统表被数据字典表上的内部系统视图所取代。影响InnoDB
INFORMATION_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或更高版本后,更新引用前面版本的脚本
InnoDB
INFORMATION_SCHEMA
视图名称。的zlib库与MySQL绑定的版本从1.2.3升级到1.2.11。
zlib
compressBound ()
与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_name来new_table_name;重命名表new_table_name来part_table_name对于每个已分区的表。请参阅文档了解更多信息。10bet官方网站
如果在升级到MySQL 8.0.17时出现此错误,请执行以下处理方法:
使用以下命令重启服务器
——升级=力
强制升级操作继续。用小写分区名称分隔符标识分区表文件名
(# #页
或# sp #
):从INFORMATION_SCHEMA中选择文件名。文件WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
对于标识的每个文件,使用临时名称重命名关联表,然后将表重命名为其原始名称。
mysql >重命名表table_name来temporary_table_name;mysql >重命名表temporary_table_name来table_name;
验证没有分区表文件名小写分区名称分隔符(应该返回一个空的结果集)。
从INFORMATION_SCHEMA中选择文件名。文件WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; Empty set (0.00 sec)
运行
分析表
在每个重命名的表上更新优化器统计信息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_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_name.table_name# p #part_1table_name# p #part_1.ibd
在升级过程中,MySQL会根据需要进行检查和修改:
在磁盘上和数据字典中分区文件名,以确保分隔符和分区名都是小写的。
在数据字典中划分元数据,以解决以前bug修复中引入的相关问题。
InnoDB
以前的bug修复中引入的相关问题的统计数据。
在表空间导入操作期间,检查并修改磁盘上的分区表空间文件名称(如果需要的话),以确保分隔符和分区名称是小写的。
在MySQL 8.0.21中,如果发现表空间数据文件位于未知的目录中,则在启动或从MySQL 5.7升级时将一个警告写入错误日志。对象定义的已知目录
datadir
,innodb_data_home_dir
,innodb_directories
变量。要使一个目录为人所知,请将它添加到innodb_directories
设置。将目录设置为已知可以确保在恢复期间可以找到数据文件。有关更多信息,请参见崩溃恢复时的表空间发现.
不兼容的更改:从MySQL 8.0.13开始,已弃用
ASC
或DESC
限定符为集团
条款已被删除。以前依赖的查询集团
排序可能会产生与以前MySQL版本不同的结果。要产生给定的排序顺序,提供一个命令
条款。查询和存储来自MySQL 8.0.12或更低版本的程序定义
ASC
或DESC
限定符为集团
条款应该修改。否则,升级到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
使用外键
值而不是生成的名称。因为每个模式(数据库)的约束名称必须是唯一的,所以由于外键索引名称对每个模式不是唯一的,所以更改会导致错误。为了避免这样的错误,MySQL 8.0.16中恢复了新的约束命名行为index_name
InnoDB
再次使用生成的约束名称。的一致性
InnoDB
,NDB
基于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-server
从latin1
来utf8mb4
.这是服务器的默认字符集。此时,UTF8MB4是web的主要字符编码,这一改变使绝大多数MySQL用户的生活变得更加轻松。从5.7升级到8.0不会改变任何现有数据库对象的字符集。但除非你具体说明character_set_server
回到之前的默认设置或显式设置字符集,然后默认使用新的模式、表或列utf8mb4
.我们建议你搬到utf8mb4
只要有可能。默认值
collation_server
系统变量和命令行参数——collation-server
从latin1_swedish_ci
来utf8mb4_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 kb
来1 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
系统变量由64
来1024
.这可以确保MySQL处理更多的警告,比如UPDATE语句触及1000行,其中许多会给出转换警告。对于许多工具来说,批量更新是很常见的,以帮助减少复制延迟。外部工具,如pt-online-schema-change默认值为1000,gh-ost默认值为100。MySQL 8.0涵盖了这两个用例的完整错误历史。因为没有静态分配,所以这个更改只会影响生成大量警告的语句的内存消耗。默认值
event_scheduler
系统变量由从
来在
.换句话说,事件调度器在默认情况下是启用的。这是SYS新特性的一个推动者,例如“杀死空闲事务”。默认值
table_open_cache
系统变量由2000
来4000
.这是一个微小的更改,它增加了表访问上的会话并发性。默认值
log_error_verbosity
系统变量由3.
(笔记)2
(警告)。这样做的目的是在默认情况下减少MySQL 8.0错误日志的冗余。
InnoDB违约
不兼容的更改默认值
innodb_undo_tablespaces
系统变量由0
来2
.配置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
系统变量由0
来1
(与对的更改结合log_bin =对
).服务器可以使用这个默认ID启动,但在实践中必须设置服务器id
根据正在部署的复制基础设施,以避免有重复的服务器id。默认值
log-slave-updates
系统变量由从
来在
.这将导致副本将复制的事件记录到自己的二进制日志中。此选项对于组复制是必需的,并且还确保各种复制链设置中的正确行为,这些设置已经成为今天的标准。默认值
expire_logs_days
系统变量由0
来30.
.新的默认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_SCAN
来INDEX_SCAN, HASH_SCAN
.这种更改通过减少复制应用程序将更改应用到没有主键的表时必须进行的表扫描次数,从而加快了基于行的复制。默认值
slave_pending_jobs_size_max
系统变量由16米
来128米
.这一更改增加了多线程副本可用的内存量。默认值
gtid_executed_compression_period
系统变量由1000
来0
.此更改确保压缩mysql.gtid_executed
表只在需要时隐式出现。
组复制默认值
默认值
group_replication_autorejoin_tries
从0更改为3,这意味着默认情况下启用自动重新连接。此系统变量指定一个成员在被驱逐或在此之前无法联系到组中的大多数成员时尝试自动重新加入组的次数group_replication_unreachable_majority_timeout
设置。默认值
group_replication_exit_state_action
从ABORT_SERVER
来READ_ONLY
.这意味着当一个成员退出组时(例如在网络故障之后),实例将变为只读,而不是关闭。默认值
group_replication_member_expel_timeout
从0更改为5,这意味着在5秒的检测周期后,怀疑与群组失去联系的成员有责任被驱逐。
这些默认设置中的大多数对于开发环境和生产环境都相当不错。但有一个例外,我们决定保留新选项innodb_dedicated_server
设置为从
尽管我们建议这样做在
在生产环境中。默认为的原因从
它是否会导致共享环境(如开发人员笔记本电脑)变得不可用,因为它需要所有它能找到的记忆。
对于生产环境,我们建议设置innodb_dedicated_server
来在
.当设置为在
下面的InnoDB变量(如果没有显式地指定)会根据可用内存自动伸缩通过innodb_buffer_pool_size
,innodb_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节,“性能模式变量表”.