mysql_upgrade也适用于我:

# mysql_upgrade -u root -p --force
# systemctl restart mysqld

问候 MFA.

在不使用-p的情况下执行以下步骤:

Mysql_upgrade -u root Systemctl restart mysqld

我也遇到过同样的问题，而且它有效!

有时mysql_upgrade -u root -p——force不够用，

请参考这个问题:表的performance_schema。Session_variables不存在

根据它:

打开cmd cd [installation_path] \ eds-binaries \ dbserver \ mysql5711x86x160420141510 \ bin Mysql_upgrade -u root -p——force

如果你的mysql根用户看起来配置错误，请尝试从mysql官方来源安装配置器扩展:

https://dev.mysql.com/downloads/repo/apt/

它将帮助您设置一个新的根用户密码。

确保更新你的存储库(debian/ubuntu):

apt-get update

因为上面的答案都不能解释发生了什么，所以我决定加入进来，为这个问题带来更多的细节。

是的，解决方案是运行MySQL升级命令，如下所示:mysql_upgrade -u root -p——force，但是发生了什么?

这个问题的根本原因是performance_schema的损坏，这可能是由以下原因引起的:

有机损坏(卷爆炸，引擎错误，内核驱动程序问题等) 在mysql补丁期间发生损坏(在mysql补丁期间发生这种情况并不是没有听说过，特别是在主要版本升级时) 简单的“删除数据库performance_schema”显然会导致此问题，并且它将呈现与已损坏相同的症状

这个问题可能在补丁之前就已经出现在你的数据库上了，但是在MySQL 5.7.8上发生的具体情况是，标志show_compatibility_56改变了它的默认值，从默认打开到关闭。这个标志控制引擎在各种MySQL版本上设置和读取变量(会话和全局)时的行为。

因为MySQL 5.7+开始在performance_schema上读取和存储这些变量，而不是在information_schema上，所以在第一个版本中，这个标志被引入为on，以减小这个变化的影响范围，并让用户知道这个变化并习惯它。

好的，但是为什么连接失败了呢?因为取决于您使用的驱动程序(及其配置)，它可能最终会为每个初始化到数据库的新连接运行命令(例如，显示变量)。因为其中一个命令可以尝试访问损坏的performance_schema，所以整个连接在完全启动之前就会中止。

因此，总而言之，您可能(现在还无法判断)在打补丁之前就已经丢失或损坏了performance_schema。5.7.8的补丁迫使引擎从performance_schema中读取变量(而不是information_schema，因为打开了标志，所以它从那里读取变量)。由于performance_schema已损坏，连接正在失败。

运行MySQL升级是最好的方法，尽管有停机时间。打开国旗是一种选择，但它有自己的一套含义，因为它已经在这篇文章中指出了。

两者都应该有效，但要权衡后果并知道你的选择:)

当使用mysql_upgrade -u root -p——force命令时，会得到以下错误:

Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13

只需在命令之前添加sudo即可。这招对我很管用，我解决了我的问题。因此，它是:sudo mysql_upgrade -u root -p——force:)