.frm表文件和 数据字典 之间的 MySQL 5.7 实例模式不匹配InnoDB可能导致升级到 MySQL 8.0 失败。这种不匹配可能是由于.frm文件损坏造成的。要解决此问题，请转储并还原受影响的表，然后再尝试升级。

如果出现问题，例如新的 mysqld服务器没有启动，请确认您没有my.cnf以前安装的旧文件。您可以使用 --print-defaults选项（例如mysqld --print-defaults）进行检查。如果此命令显示程序名称以外的任何内容，则您有一个my.cnf影响服务器或客户端操作的活动文件。

如果在升级后，您在编译客户端程序时遇到问题，例如Commands out of sync或意外的核心转储，您可能在编译程序时使用了旧的头文件或库文件。在这种情况下，请检查 mysql.h文件和 libmysqlclient.a库的日期以验证它们是否来自新的 MySQL 发行版。如果没有，请使用新的头文件和库重新编译您的程序。libmysqlclient.so.20如果库的主要版本号已更改（例如，从到 libmysqlclient.so.21） ，则针对共享客户端库编译的程序也可能需要重新编译 。

如果您创建了一个具有给定名称的可加载函数并将 MySQL 升级到一个实现了具有相同名称的新内置函数的版本，则该可加载函数将变得不可访问。要更正此问题，请使用DROP FUNCTION删除可加载函数，然后使用 CREATE FUNCTION重新创建具有不同的非冲突名称的可加载函数。如果新版本的 MySQL 实现了一个与现有存储函数同名的内置函数，情况也是如此。有关描述服务器如何解释对不同类型函数的引用的规则， 请参见第 9.2.5 节，“函数名称解析和解析” 。

如果升级到 MySQL 8.0 由于第 2.11.5 节“准备升级安装”中列出的任何问题而失败，服务器将恢复对数据目录的所有更改。在这种情况下，删除所有重做日志文件并在现有数据目录上重新启动 MySQL 5.7 服务器以解决错误。默认情况下，重做日志文件 ( ib_logfile*) 驻留在 MySQL 数据目录中。修复错误后，在 innodb_fast_shutdown=0再次尝试升级之前执行缓慢关闭（通过设置）。