升级路径
支持从MySQL 5.7升级到8.0。但是，仅在一般可用性(GA)版本之间支持升级。对于MySQL 8.0，要求您从MySQL 5.7 GA版本(5.7.9或更高版本)升级。不支持从非GA版本的MySQL 5.7升级。
建议先升级到最新版本，再升级到下一版本。例如，在升级到MySQL 8.0之前，先升级到最新的MySQL 5.7版本。
不支持跳过版本的升级。例如，不支持从MySQL 5.6直接升级到8.0。
一旦发布系列达到通用(GA)状态，就支持在该发布系列内升级(从一个GA版本升级到另一个GA版本)。例如，从MySQL 8.0升级。x到8.0。y支持。(不支持涉及开发状态非GA版本的升级。)还支持跳过版本。例如，从MySQL 8.0升级。x到8.0。z支持。MySQL 8.0.11是MySQL 8.0发行系列中的第一个GA状态发行版。
MySQL升级过程将升级什么
安装新版本的MySQL可能需要升级现有安装的以下部分：
1、该mysql系统架构，其中包含存储由它运行MySQL服务器所需的信息表(见第5.3节，“MySQL的系统架构”)。 mysql模式表分为两大类：
数据字典表，用于存储数据库对象元数据。
系统表(即剩余的非数据字典表)，用于其他操作目的。
2、其他模式，其中一些是内置的，可能被服务器视为“ 拥有 ”，而其他则不是：
性能架构 INFORMATION_SCHEMA，和 sys架构。
用户架构。
两个不同的版本号与可能需要升级的安装部分相关联：
数据字典版本。这适用于数据字典表。
服务器版本，也称为MySQL版本。这适用于其他模式中的系统表和对象。
在这两种情况下，适用于现有MySQL安装的实际版本都存储在数据字典中，而当前的预期版本将编译为MySQL的新版本。当实际版本低于当前预期版本时，必须将与该版本关联的安装的那些部分升级到当前版本。如果两个版本均指示需要升级，则必须首先进行数据字典升级。
作为上述两个不同版本的反映，升级分两个步骤进行：
1、步骤1：资料字典升级。
此步骤升级：
模式中的数据字典表mysql 。如果实际数据字典版本低于当前预期版本，则服务器将创建具有更新定义的数据字典表，将持久化的元数据复制到新表中，用新表原子替换旧表，然后重新初始化数据字典。
性能架构和性能 INFORMATION_SCHEMA。
2、步骤2：服务器升级。
此步骤包括所有其他升级任务。如果现有MySQL安装的服务器版本低于新安装的MySQL版本，则必须升级所有其他产品：
模式中的系统表mysql(其余的非数据字典表)。
该sys架构。
用户架构。
数据字典升级(步骤1)由服务器负责，服务器在启动时会根据需要执行此任务，除非使用阻止它执行此操作的选项进行调用。该选项--upgrade=NONE自MySQL 8.0.16起，--no-dd-upgrade早于MySQL 8.0.16。
如果数据字典已过期，但是服务器无法对其进行升级，则服务器将无法运行并退出并出现错误。例如：
[ERROR] [MY-013381] [Server] Server shutting down because upgrade is
required, yet prohibited by the command line option '--upgrade=NONE'.
[ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
在MySQL 8.0.16中对步骤2的职责进行了一些更改：
在MySQL 8.0.16之前，mysql_upgrade 升级性能架构， INFORMATION_SCHEMA步骤2中描述的对象和对象。启动服务器后，期望DBA 手动调用 mysql_upgrade。
从MySQL 8.0.16开始，服务器执行以前由mysql_upgrade处理的所有任务。尽管升级仍然需要两步操作，但是服务器会同时执行这两项操作，从而简化了过程。
根据要升级到的MySQL版本，就地升级和 逻辑升级中的说明指示服务器是执行所有升级任务还是在服务器启动后还必须调用 mysql_upgrade。
注意
由于服务器INFORMATION_SCHEMA从MySQL 8.0.16开始升级了Performance Schema 和第2步中描述的对象，因此 从该版本开始不再需要mysql_upgrade并已弃用，并将在以后的MySQL版本中将其删除。
尽管可能需要不同的命令选项才能达到特定的效果，但步骤2期间发生的大多数方面与MySQL 8.0.16之前的版本相同。
从MySQL 8.0.16开始，--upgrade 服务器选项控制启动时服务器是否以及如何执行自动升级：
不带或不带选项 --upgrade=AUTO，服务器将升级它确定为过期的任何内容(步骤1和2)。
使用--upgrade=NONE，服务器不进行任何升级(跳过步骤1和2)，但是如果必须升级数据字典，也会退出并出现错误。不能使用过期的数据字典来运行服务器。服务器坚持要升级或退出。
使用--upgrade=MINIMAL，服务器将升级数据字典，性能架构和INFORMATION_SCHEMA，如果需要的话(步骤1)。请注意，使用此选项升级之后，将无法启动组复制，因为复制内部所依赖的系统表未更新，并且降低的功能在其他方面也很明显。
使用--upgrade=FORCE，服务器将升级数据字典，性能模式和INFORMATION_SCHEMA，如果需要的话(步骤1)，并强制升级其他所有内容(步骤2)。期望使用该选项启动服务器会花费更长的时间，因为服务器会检查所有架构中的所有对象。
FORCE如果服务器认为不必要执行第二步操作，则可以强制执行该操作。与的一种FORCE不同方式AUTO 是，FORCE如果缺少，服务器将重新创建系统表，例如帮助表或时区表。
以下列表显示了MySQL 8.0.16之前的升级命令以及MySQL 8.0.16及更高版本的等效命令：
1、执行常规升级(必要时执行步骤1和2)：
在MySQL 8.0.16之前：mysqld，后跟mysql_upgrade
从MySQL 8.0.16开始：mysqld
2、根据需要仅执行步骤1：
在MySQL 8.0.16之前：不能执行步骤1中描述的所有升级任务，而不能排除步骤2中描述的任务。但是，可以避免sys使用mysqld和 mysql_upgrade(带有 --upgrade-system-tables 和 --skip-sys-schema 选项)升级用户模式和模式 。
从MySQL 8.0.16开始：mysqld --upgrade = MINIMAL
3、根据需要执行步骤1，然后强制执行步骤2：
在MySQL 8.0.16之前：mysqld后跟mysql_upgrade --force
从MySQL 8.0.16开始：mysqld --upgrade = FORCE
在MySQL 8.0.16之前，某些mysql_upgrade 选项会影响其执行的操作。下表显示了--upgrade从MySQL 8.0.16开始使用的服务器选项值，以实现类似的效果。(这些不一定完全相同，因为给定的 --upgrade期权价值可能会有其他影响。)
mysql_upgrade选项 服务器选件
--skip-sys-schema --upgrade=NONE 要么 --upgrade=MINIMAL
--upgrade-system-tables --upgrade=NONE 要么 --upgrade=MINIMAL
--force --upgrade=FORCE
有关升级步骤2中发生的事情的其他说明：
sys如果尚未安装架构，则 第2步将安装该架构，否则将其升级到当前版本。如果sys存在一个架构但没有version视图，那么会发生错误，并假设该架构的缺失表示用户创建的架构：A sys schema exists with no sys.version view. If
you have a user created sys schema, this must be renamed for the
upgrade to succeed.在这种情况下，要进行升级，请先删除或重命名现有 sys架构。然后再次执行升级过程。(可能有必要强制执行步骤2。)
为防止sys模式检查：
从MySQL 8.0.16开始：使用--upgrade=NONE或 --upgrade=MINIMAL选项启动服务器 。
在MySQL 8.0.16之前：使用该 选项调用 mysql_upgrade--skip-sys-schema。
步骤2根据需要处理所有用户模式中的所有表。表检查可能需要很长时间才能完成。每个表都被锁定，因此在处理它时其他会话无法使用。检查和修复操作可能很耗时，特别是对于大桌子。表检查使用语句的FOR UPGRADE选项 CHECK TABLE。有关此选项的含义的详细信息，请参见 第13.7.3.2节“检查表语法”。
为了防止表格检查：
从MySQL 8.0.16开始：使用--upgrade=NONE或 --upgrade=MINIMAL选项启动服务器 。
在MySQL 8.0.16之前：使用该 选项调用 mysql_upgrade--upgrade-system-tables。
强制进行表检查：
从MySQL 8.0.16开始：使用--upgrade=FORCE选项启动服务器 。
在MySQL 8.0.16之前：使用该 选项调用 mysql_upgrade--force。
步骤2将MySQL版本号保存mysql_upgrade_info在data目录中命名的文件 中。
要忽略mysql_upgrade_info文件并执行检查，无论如何：
从MySQL 8.0.16开始：使用--upgrade=FORCE选项启动服务器 。
在MySQL 8.0.16之前：使用该 选项调用 mysql_upgrade--force。
注意
该mysql_upgrade_info文件已弃用，并将在以后的MySQL版本中删除。
步骤2使用当前的MySQL版本号标记所有已检查和已修复的表。这样可以确保下次使用相同版本的服务器进行升级检查时，可以确定是否需要再次检查或修复给定的表。
步骤2升级系统表以确保它们具有当前结构。无论服务器还是mysql_upgrade执行该步骤，都是如此 。关于帮助表和时区表的内容，mysql_upgrade不会加载这两种类型的表，而服务器会加载帮助表，但不会加载时区表。(也就是说，在MySQL 8.0.16之前，服务器仅在数据目录初始化时加载帮助表。从MySQL 8.0.16开始，它在初始化和升级时加载帮助表。)加载时区表的过程它取决于平台，需要DBA做出决策，因此无法自动完成。
MySQL 8.0中的更改
升级到MySQL 8.0之前，请查看本节中描述的更改，以识别适用于当前MySQL安装和应用程序的更改。执行任何建议的操作。
标为“ 不兼容的更改”的更改与MySQL的早期版本不兼容，在升级之前可能需要引起您的注意。我们的目标是避免这些更改，但是有时它们对于纠正比发行版之间的不兼容性更严重的问题是必要的。如果适用于您的安装的升级问题涉及不兼容问题，请按照说明中给出的说明进行操作。
数据字典更改
caching_sha2_password作为首选身份验证插件
配置变更
服务器变更
InnoDB的变化
SQL变更
数据字典更改
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_password为 caching_sha2_password。
此更改仅适用于在安装或升级到MySQL 8.0或更高版本后创建的新帐户。对于升级安装中已经存在的帐户，其身份验证插件保持不变。希望切换到的现有用户caching_sha2_password 可以使用以下ALTER USER语句：
ALTER USER user
IDENTIFIED WITH caching_sha2_password
BY 'password';
该libmysqlclient库被视为 caching_sha2_password默认的身份验证插件，而不是 mysql_native_password。
以下各节讨论了更重要角色的含义caching_sha2_password：
caching_sha2_password兼容性问题和解决方案
caching_sha2_password兼容的客户端和连接器
caching_sha2_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可能无法连接到配置caching_sha2_password为默认身份验证插件的MySQL 8.0服务器 ，甚至无法使用不通过进行身份验证的帐户caching_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]
有关编写连接器以妥善处理来自服务器的未知默认身份验证插件请求的信息，请参阅 身份验证插件连接器编写注意事项。
使用进行身份验证的帐户的客户端 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_native_password该帐户的帐户 (以前的默认身份验证插件)，除非使用一个 --default-auth=mysql_native_password 选择。
libmysqlclient8.0之前版本的MySQL 的客户端库能够连接到MySQL 8.0服务器(使用进行身份验证的帐户除外 caching_sha2_password)。这意味着基于8.0之前版本的客户端libmysqlclient也应该能够连接。例子：
标准MySQL客户端(例如mysql和 mysqladmin)是 libmysqlclient基于-的。
Perl DBI的DBD :: mysql驱动程序是 libmysqlclient基于-的。
MySQL Connector / Python具有基于C的C扩展模块 libmysqlclient。要使用它，请use_pure=False在连接时包括该选项。
当现有的MySQL 8.0安装升级到MySQL 8.0.4或更高版本时，某些libmysqlclient基于旧 客户端的客户端如果被动态链接，则可能会 “ 自动 ”升级，因为它们使用升级安装的新客户端库。例如，如果用于Perl DBI的DBD :: mysql驱动程序使用动态链接，则libmysqlclient在升级到MySQL 8.0.4或更高版本后，它可以在适当的位置使用 in，结果如下：
升级之前，使用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。(需要Connector / 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 Connector / Python脚本可以指定 auth_plugin连接选项。(或者，使用连接器/ Python C扩展，它可以连接到MySQL 8.0服务器，而无需使用 auth_plugin。)
caching_sha2_password兼容的客户端和连接器
如果已经更新了一个已知的客户端或连接器caching_sha2_password，则使用它是确保连接到配置caching_sha2_password为默认身份验证插件的MySQL 8.0服务器时兼容性的最佳方法 。
这些客户端和连接器已升级为支持 caching_sha2_password：
libmysqlclientMySQL 8.0(8.0.4或更高版本)中 的客户端库。标准的MySQL客户端(例如 mysql和mysqladmin) 是libmysqlclient基于-的，因此它们也兼容。
libmysqlclientMySQL 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，身份验证插件的现有帐户(包括'root'@'localhost'管理帐户的插件)保持不变 。
对于新安装的MySQL 8.0，在初始化数据目录(使用 第2.10.1节“初始化数据目录”中的说明)时，将'root'@'localhost'创建该 帐户，并且caching_sha2_password默认情况下使用该帐户。要在数据目录初始化之后连接到服务器，必须使用支持的客户端或连接器caching_sha2_password。如果可以执行此操作，但希望在安装后root使用该帐户mysql_native_password，请照常安装MySQL并初始化数据目录。然后以以下方式连接到服务器，root并使用ALTER USER以下方法更改帐户身份验证插件和密码：
ALTER USER 'root'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'password';
如果您使用的客户端或连接器尚不支持 caching_sha2_password，则可以使用修改后的数据目录初始化过程，该过程将在创建root帐户后 mysql_native_password立即将其与之关联 。为此，请使用以下两种技术之一：
--default-authentication-plugin=mysql_native_password 与--initialize或 一起提供 一个 选项 --initialize-insecure。
在选项文件中 设置 default_authentication_plugin 为mysql_native_password，然后使用--defaults-file选项--initialize或或 命名该选项文件 --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用于主/从复制的帐户：
使用以下任何CHANGE MASTER TO选项：
MASTER_SSL = 1
GET_MASTER_PUBLIC_KEY = 1
MASTER_PUBLIC_KEY_PATH='path to RSA public key file'
或者，如果在服务器启动时提供了必需的密钥，则可以使用与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 = 'path to RSA public key file';
或者，如果在服务器启动时提供了必需的密钥，则可以使用与RSA公用密钥相关的选项。
配置变更
不兼容的更改：MySQL存储引擎现在负责提供其自己的分区处理程序，而MySQL服务器不再提供常规分区支持。 InnoDB并且 NDB是唯一提供MySQL 8.0支持的本机分区处理程序的存储引擎。在 升级服务器之前，必须更改使用任何其他存储引擎的分区表(将其转换为 InnoDB或NDB，或删除其分区)，否则此后将无法使用。
有关将MyISAM 表转换为的信息InnoDB，请参见 第15.6.1.3节“将表从MyISAM转换为InnoDB”。
在没有这种支持的情况下，使用存储引擎将导致分区表的表创建语句失败，并在MySQL 8.0中出现错误(ER_CHECK_NOT_IMPLEMENTED)。如果从使用mysqldump在MySQL 5.7(或更早版本)中创建的转储文件中将数据库导入 MySQL 8.0服务器，则必须确保通过删除对分区的任何引用来创建分区表的任何语句也未指定不受支持的存储引擎。 ，或者将存储引擎指定为 InnoDB或允许将其InnoDB默认设置为 。
注意
第2.11.5节“为升级准备安装”中 给出的过程 描述了如何识别在升级到MySQL 8.0之前必须更改的分区表。
有关更多信息，请参见 第23.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中，已删除了一些与帐户管理有关的不赞成使用的功能，例如使用该 GRANT语句修改用户帐户的非特权特征， NO_AUTO_CREATE_USERSQL模式， PASSWORD()函数和 old_passwords系统变量。
从MySQL 5.7到引用这些已删除功能的语句的复制可能会导致复制失败。使用任何已删除功能的应用程序都应进行修改，以避免使用它们，并尽可能使用替代方法，如MySQL 8.0中已删除功能中所述。
为了避免在MySQL 8.0上启动失败，请NO_AUTO_CREATE_USER从 sql_modeMySQL选项文件中的系统变量设置中删除任何实例。
将包含已NO_AUTO_CREATE_USER存储程序定义中的SQL模式的转储文件加载 到MySQL 8.0服务器中会导致失败。从MySQL 5.7.24和MySQL 8.0.13开始， mysqldumpNO_AUTO_CREATE_USER从存储的程序定义中删除 。mysqldump必须手动修改使用早期版本创建的转储文件， 以删除的实例NO_AUTO_CREATE_USER。
在MySQL 8.0.11，这些过时兼容性SQL模式被拆除：DB2， MAXDB，MSSQL， MYSQL323，MYSQL40， ORACLE，POSTGRESQL， NO_FIELD_OPTIONS， NO_KEY_OPTIONS， NO_TABLE_OPTIONS。它们不能再分配给sql_mode系统变量或用作mysqldump --compatible选项的允许值 。
删除MAXDB意味着 TIMESTAMP数据类型为 CREATE TABLE或 ALTER TABLE不再被视为DATETIME。
从MySQL 5.7到引用已删除的SQL模式的语句的复制可能会导致复制失败。这包括复制CREATE在当前sql_mode值包括任何已删除模式时执行的存储程序(存储过程和功能，触发器和事件)的语句 。使用任何已删除模式的应用程序都应进行修改以避免它们。
从MySQL 8.0.3开始，空间数据类型允许使用 SRID属性，以明确指示存储在列中的值的空间参考系统(SRS)。请参见第11.5.1节“空间数据类型”。
具有显式SRID 属性的空间列受SRID限制：该列仅接受具有该ID的值，并且SPATIAL该列上的索引成为优化器可以使用的对象。优化器将忽略SPATIAL没有SRID属性的空间列上的索引。请参见 第8.3.3节“空间索引优化”。如果要让优化器考虑SPATIAL不受SRID限制的空间列上的索引，则应修改每个这样的列：
验证列中的所有值都具有相同的SRID。要确定几何列中包含的SRID col_name，请使用以下查询：
SELECT DISTINCT ST_SRID(col_name) FROM tbl_name;
如果查询返回多个行，则该列包含SRID的混合。在这种情况下，请修改其内容，以便所有值都具有相同的SRID。
重新定义该列以具有显式 SRID属性。
重新创建SPATIAL索引。
由于空间功能名称空间的更改(实现了ST执行精确操作MBR的功能的前缀或基于最小边界矩形执行操作的功能的前缀)，MySQL 8.0.0中删除了一些空间功能 。在生成的列定义中使用删除的空间函数可能会导致升级失败。升级之前，运行mysqlcheck --check-upgrade删除已删除的空间函数，并用其ST 或MBR命名的替换项替换找到的任何空间函数。有关已删除的空间函数的列表，请参阅MySQL 8.0中已删除的功能。 。
当执行就地升级到MySQL 8.0.3或更高版本时 ，BACKUP_ADMIN特权将自动授予具有RELOAD特权的用户 。
从MySQL 8.0.13开始，由于在处理临时表的方式上基于行或混合复制模式与基于语句的复制模式之间存在差异，因此在运行时切换二进制日志记录格式存在新的限制。
SET @@SESSION.binlog_format 如果会话具有任何打开的临时表，则不能使用。
SET @@global.binlog_format并且SET @@persist.binlog_format如果任何复制通道具有任何打开的临时表， 则不能使用。SET @@persist_only.binlog_format如果复制通道具有打开的临时表，则允许使用该方法，因为与不同PERSIST， PERSIST_ONLY它不会修改运行时全局系统变量值。
SET @@global.binlog_format并且SET @@persist.binlog_format如果正在运行任何复制通道应用程序， 则无法使用。这是因为更改仅在重新启动其应用程序时才在复制通道上生效，此时复制通道可能具有打开的临时表。此行为比以前更严格。SET @@persist_only.binlog_format如果有任何复制渠道申请者正在运行，则允许使用。
InnoDB的变化
INFORMATION_SCHEMA基于InnoDB系统表的视图被数据字典表上的内部系统视图替换。受影响的 InnoDB INFORMATION_SCHEMA视图已重命名：
表2.15重命名的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视图名称的脚本。
与MySQL捆绑在一起 的zlib库版本从1.2.3版本提高到1.2.11版本。
compressBound()zlib 1.2.11中 的zlib 函数返回的压缩给定字节长度所需的缓冲区大小的估计值比zlib 1.2.3版中的缓冲区大小略高。该compressBound() 函数由InnoDB确定在创建压缩InnoDB表或在压缩InnoDB 表中插入和更新行时所允许的最大行大小的函数调用。其结果是， CREATE TABLE ... ROW_FORMAT=COMPRESSED， INSERT，和 UPDATE与行大小非常接近最大行大小的是成功的早期版本，现在可能无法操作。为避免此问题，请CREATE TABLE 对压缩的测试语句InnoDB 升级之前，MySQL 8.0测试实例上具有大行的表。
引入此 --innodb-directories 功能后，应将使用绝对路径创建的每表文件和常规表空间文件的位置或数据目录外部的位置添加到innodb_directories 参数值。否则，InnoDB将无法在恢复过程中找到这些文件。要查看表空间文件位置，请查询 INFORMATION_SCHEMA.FILES表：
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实例中存在的所有撤消表空间都将被删除，并由两个新的默认撤消表空间代替。默认撤消表空间在innodb_undo_directory 变量定义的位置中创建 。如果 innodb_undo_directory 未定义变量，则在数据目录中创建撤消表空间。从MySQL 5.7升级到MySQL 8.0需要缓慢关闭，以确保MySQL 5.7实例中的撤消表空间为空，从而可以安全地删除它们。
从较早的MySQL 8.0版本升级到MySQL 8.0.14或更高版本时，由于innodb_undo_tablespaces 设置大于2而导致在升级前实例中存在的撤消表空间 被视为用户定义的撤消表空间，可以将其停用并删除升级后分别使用 ALTER UNDO TABLESPACE和 DROP UNDO TABLESPACE语法。在MySQL 8.0版本系列中进行升级可能并不总是需要缓慢的关闭，这意味着现有的撤消表空间可能包含撤消日志。因此，升级过程不会删除现有的撤消表空间。
不兼容的更改：从MySQL 8.0.17开始，该 CREATE TABLESPACE ... ADD DATAFILE子句不允许循环目录引用。例如，/../以下语句中的循环目录引用()是不允许的：
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd '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：
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时遇到此错误，请执行以下解决方法：
重新启动服务器 --upgrade=force以强制进行升级操作。
用小写的分区名定界符(#p#或来 标识分区表文件名#sp#：
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
对于标识的每个文件，请使用临时名称重命名关联的表，然后将表重命名为其原始名称。
mysql> RENAME TABLE table_name TO temporary_table_name;
mysql> RENAME TABLE temporary_table_name TO table_name;
验证没有分区表文件名小写的分区名定界符(应返回空结果集)。
mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)
ANALYZE TABLE在每个重命名的表上 运行，以更新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_name
table_name#p#partition_name#sp#subpartition_name.ibd
从历史上看，分隔符字符串在区分大小写的文件系统(例如Linux)上是大写(#P#和#SP#)，在不区分大小写的文件系统(例如Windows)上是小写的(#p#和#sp#)。从MySQL 8.0.19开始，分隔符字符串在所有文件系统上均为小写。此更改可防止在区分大小写和不区分大小写的文件系统之间迁移数据目录时出现问题。大写分隔符字符串不再使用。
此外，现在可以根据用户指定的分区或子分区名称生成分区表空间名称和文件名，这些名称可以以大写或小写形式指定，无论lower_case_table_names 设置如何确保不区分大小写，都以小写形式生成(并内部存储) 。例如，如果使用name创建表分区 PART_1，则表空间名称和文件名以小写形式生成：
schema_name.table_name#p#part_1
table_name#p#part_1.ibd
在升级期间，MySQL会根据需要检查和修改：
在磁盘上和数据字典中对文件名进行分区，以确保小写的分隔符和分区名。
对数据字典中的元数据进行分区，以解决以前的错误修复所引入的相关问题。
InnoDB 先前的错误修复所引入的相关问题的统计数据。
在表空间导入操作期间，将检查磁盘上的分区表空间文件名，并在必要时进行修改，以确保小写定界符和分区名。
SQL变更
不兼容的更改：从MySQL 8.0.13开始，不赞成使用的子句ASC或 DESC限定词GROUP BY已被删除。先前依赖于GROUP BY排序的查询所产生的结果可能与以前的MySQL版本不同。要产生给定的排序顺序，请提供一个ORDER BY子句。
MySQL 8.0.12或更低版本中对子句使用ASC或 DESC限定符的查询和存储程序定义GROUP BY应进行修改。否则，升级到MySQL 8.0.13或更高版本可能会失败，可能会复制到MySQL 8.0.13或更高版本的从属服务器。
一些关键字可能在MySQL 8.0中保留，而在MySQL 5.7中未保留。请参见 第9.3节“关键字和保留字”。这可能导致以前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引号。请参见 第9.2节“模式对象名称”。
升级后，建议您测试应用程序代码中指定的优化器提示，以确保仍需要这些提示来实现所需的优化策略。优化器增强有时可能使某些优化器提示不必要。在某些情况下，不必要的优化器提示甚至可能适得其反。
不兼容的更改：在MySQL 5.7中，FOREIGN KEY 为InnoDB不带子句的表 指定定义，或不带关键字的关键字导致 使用生成的约束名称。在MySQL 8.0中，该行为发生了变化， 使用了值而不是生成的名称。因为约束名称对于每个架构(数据库)必须是唯一的，所以由于外键索引名称不是每个架构唯一，因此更改会导致错误。为避免此类错误，MySQL 8.0.16中已恢复了新的约束命名行为，并且 CONSTRAINT symbolCONSTRAINTsymbolInnoDBInnoDBFOREIGN KEY index_nameInnoDB 再次使用生成的约束名称。
为了与保持一致InnoDB，NDB如果未指定子句或指定的关键字不带，则 基于MySQL 8.0.16或更高版本的版本使用生成的约束名称 。 基于MySQL 5.7和更低版本的MySQL 8.0发行版使用该值。 CONSTRAINT symbolCONSTRAINTsymbolNDBFOREIGN KEY index_name
上述更改可能会为依赖于先前外键约束命名行为的应用程序带来不兼容性。
扫一扫
1061
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
