在运行@robregonm建议的命令后，我能够登录mysql服务器:

mysql_upgrade -u root -p --force

需要重新启动MySQL服务器。

在运行@robregonm建议的命令后，我能够登录mysql服务器:

mysql_upgrade -u root -p --force

需要重新启动MySQL服务器。

mysql_upgrade也适用于我:

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

问候 MFA.

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

Mysql_upgrade -u root Systemctl restart mysqld

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

mysql -u app -p
mysql> set @@global.show_compatibility_56=ON;

http://bugs.mysql.com/bug.php?id=78159对我有用。

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

是的，解决方案是运行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升级是最好的方法，尽管有停机时间。打开国旗是一种选择，但它有自己的一套含义，因为它已经在这篇文章中指出了。

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