在升级到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相同密码”;
的
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
选择。
的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
选择。使用本地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
:
的
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
.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
一旦创建了帐户。要做到这一点,可以使用以下任何一种技巧:
提供一个
——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
源/副本复制帐号:
使用以下任何一种方法
改变主
选项: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支持的本地分区处理程序的存储引擎。必须修改使用任何其他存储引擎的分区表,以便将其转换为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复制到MySQL 8.0会导致复制失败。应该修改使用任何被删除功能的应用程序,以避免使用它们,并在可能的情况下使用替代功能,如MySQL 8.0删除功能.
为避免在MySQL 8.0上启动失败,请删除
NO_AUTO_CREATE_USER
从sql_mode
MySQL选项文件中的系统变量设置。的转储文件正在加载
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模式被移除:
DB2
,MAXDB
,该软件
,MYSQL323
,MYSQL40
,甲骨文
,POSTGRESQL
,NO_FIELD_OPTIONS
,NO_KEY_OPTIONS
,NO_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。确定几何列中包含的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信息模式视图
旧的名称 新名字 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.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_name来new_table_name;重命名表new_table_name来part_table_name'为每个分区表。有关进一步信息,请参阅文档。10bet官方网站
如果在升级到MySQL 8.0.17时遇到此错误,请执行以下解决方法:
使用以下命令重新启动服务器
——升级=力
强制升级操作继续进行。用小写分区名分隔符标识分区表文件名
(# #页
或# sp #
):mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA文件WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
对于标识的每个文件,使用临时名称重命名关联的表,然后将表重命名为其原始名称。
mysql >重命名表table_name来temporary_table_name;mysql >重命名表temporary_table_name来table_name;
验证不存在分区表文件名、小写分区名分隔符(应该返回一个空结果集)。
mysql> SELECT FILE_NAME FROM 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 #
),而小写(# 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会根据需要进行检查和修改:
磁盘上和数据字典中的分区文件名,以确保小写分隔符和分区名称。
分区数据字典中的元数据,以解决以前的错误修复程序引入的相关问题。
InnoDB
以前的错误修复程序引入的相关问题的统计数据。
在表空间导入操作期间,如果需要,将检查和修改磁盘上的分区表空间文件名,以确保小写分隔符和分区名称。
从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 8.0中可能保留了MySQL 5.7中没有保留的一些关键字。看到第9.3节“关键词和保留词”.这可能导致以前用作标识符的单词变成非法的。要修复受影响的语句,请使用标识符引号。看到第9.2节“模式对象名称”.
在升级之后,建议您测试应用程序代码中指定的优化器提示,以确保实现所需的优化策略仍然需要这些提示。优化器增强有时会使某些优化器提示变得不必要。在某些情况下,不必要的优化提示甚至可能适得其反。
不兼容的更改:在MySQL 5.7中,指定a
外键
定义为一个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 |
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-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表空间的数量。的最小值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
系统变量从0
来1
(结合到log_bin =对
).可以使用这个默认ID启动服务器,但实际上必须设置服务器id
根据正在部署的复制基础设施,避免有重复的服务器id。的默认值
log-slave-updates
系统变量从从
来在
.这将导致副本将复制的事件记录到它自己的二进制日志中。此选项是Group Replication所必需的,并且还确保了在各种复制链设置中的正确行为,这已成为当今的规范。的默认值
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秒检测周期后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节“性能模式变量_info表”.