表“performance_schema.session_variables”不存在答案

【问题标题】：Table 'performance_schema.session_variables' doesn't exist表“performance_schema.session_variables”不存在
【发布时间】：2015-11-05 04:46:36
【问题描述】：

将 MySQL 升级到 5.7.8-rc 后并登录到服务器我得到了错误：

Table 'performance_schema.session_variables' doesn't exist

我找不到任何解决方案。你能帮忙吗？

【问题讨论】：

另一个。看来您的升级没有成功。您可能需要考虑再次执行升级过程（或）重新安装5.7.8-rc 版本并从数据库完整备份恢复。
您是否运行mysql_upgrade 以确保对核心表/数据库的任何更改都已完成？
是的，我创建了mysql_upgrade，我最后一次尝试并重新安装它。如果它不起作用，我将降级到 5.6 版本
我遇到了同样的问题，为了解决它，我运行mysql_upgrade -u root -p --force，然后我重新启动了数据库服务器。
如果 mysql_upgrade 命令不起作用，则 mysql.performance_schema 表可能已损坏。我们遇到了这个问题。为了解决这个问题，我们使用以下命令删除了数据库服务器：apt-get purge mariadb-client-10.1 mariadb-common mariadb-server-10.1。这删除了所有数据库二进制文件、配置和数据文件。接下来我们重新安装数据库服务器并导入数据库。之后数据库服务器运行没有问题

标签： mysql upgrade

【解决方案1】：

由于上述答案都没有真正解释发生了什么，我决定插话并为这个问题带来更多细节。

是的，解决方法是运行 MySQL Upgrade 命令，如下：mysql_upgrade -u root -p --force，但是发生了什么？

这个问题的根本原因是performance_schema的损坏，这可能是由于：

有机损坏（卷出现故障、引擎错误、内核驱动程序问题等）
mysql 补丁期间损坏（在 mysql 补丁期间发生这种情况并非闻所未闻，特别是对于主要版本升级）
一个简单的“drop database performance_schema”显然会导致这个问题，并且会出现与损坏相同的症状

这个问题可能在补丁发布之前就已经存在于您的数据库中，但在 MySQL 5.7.8 上发生的具体情况是标志 show_compatibility_56 将其默认值从默认设置为 ON 更改为 OFF .此标志控制引擎在查询时如何在各种 MySQL 版本上设置和读取变量（会话和全局）。

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

好的，但是为什么连接失败？因为根据您使用的驱动程序（及其配置），它最终可能会为每个启动到数据库的新连接运行命令（例如show variables）。因为这些命令之一可以尝试访问损坏的performance_schema，所以整个连接在完全启动之前中止。

因此，总而言之，您可能（现在无法判断）在修补之前丢失或损坏了performance_schema。 5.7.8 的补丁然后强制引擎从performance_schema 中读取您的变量（而不是information_schema，因为标志被打开ON 而从那里读取它）。由于performance_schema 已损坏，因此连接失败。

运行 MySQL 升级是最好的方法，尽管有停机时间。打开标志是一种选择，但它有其自身的一套含义，正如已经在此线程中指出的那样。

两者都应该有效，但要权衡后果并了解您的选择:)

【讨论】：

谢谢。在着手进行更改之前，我想知道是什么导致了这个问题。
@MarcelloGrechiLins 非常感谢您的解释。能够真正解释问题所在以及答案为何有效，这确实是一件好事。
我很高兴能提供帮助。这个问题真的很可疑，我知道它会影响数千个数据库。大多数人根本没有时间或手段深入研究。

【解决方案2】：

在没有-p 的情况下执行以下步骤：

mysql_upgrade -u root
systemctl restart mysqld

我遇到了同样的问题，但它有效！

【讨论】：

这行得通！只有systemctl restart mysqld 不起作用。
然后使用systemctl restart mysql

【解决方案3】：

如果在使用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 :)

【讨论】：

【解决方案4】：

对于我的系统，问题最终是我仍然安装了 Mysql 5.6，因此调用了该安装中的 mysql_upgrade.exe 而不是 5.7 的那个。导航到C:\Program Files\MySQL\MySQL Server 5.7\bin 并运行.\mysql_upgrade.exe -u root

【讨论】：

【解决方案5】：

有时mysql_upgrade -u root -p --force 还不够，

请参考这个问题：Table 'performance_schema.session_variables' doesn't exist

据此：

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

【讨论】：

【解决方案6】：

作为 604 位的问题，如果你的 mysql root 用户看起来配置错误，请尝试从 mysql 官方源安装配置器扩展：

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

它将帮助您设置新的root用户密码。

确保更新您的存储库（debian/ubuntu）：

apt-get update

【讨论】：

【解决方案7】：

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

根据 http://bugs.mysql.com/bug.php?id=78159 为我工作。

【讨论】：

这对我来说非常有效！而且我不必重新启动mysql服务器，这会很麻烦
对不起，这是一个有点过大的解决方案：就像用火箭筒射苍蝇一样。此兼容性开关有更多效果，您可能不需要所有效果。
@Tuncay Göncüoğlu 这些副作用是什么？
@katzmopolitan 在此处阅读：dev.mysql.com/doc/refman/5.7/en/…。这些更改主要与 INFORMATION_SCHEMA 处理（安全等）有关，但还有更多。
这对我也有用。我收到的错误消息来自 mysqldump。一旦我进行了建议的更改，mysqldump 就起作用了。完成转储后，我只需将 show_compatibility_56 改回 OFF。

【解决方案8】：

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

mysql_upgrade -u root -p --force

需要重启 MySQL 服务器。

【讨论】：

效果很好。谢谢。我想知道是什么原因。
我收到了Access denied for user 'root'@'localhost' (using password: YES) while connecting to the MySQL server，即使我使用的是正确的 root 密码。有什么帮助吗？？ :-/
@sixty4bit 尝试删除 -p
@NevilleNazerane 我不熟悉简单的 php，但您应该能够找到安装 mysql 的位置，然后只需打开 cdm 提示符并将目录更改为该位置。现在你应该可以运行命令了。
@diguage 原因是 MySQL 的版本升级为内部元数据引入了版本不兼容的 schema。对我来说，我正在使用 Homebrew 在 Mac 上将 MySQL 5.6 升级到 MySQL 5.7，并且 MySQL 数据目录未更改，因此新版本 MySQL 正在读取旧的内部元数据但不知道该怎么做 - 我们在这里看到的错误是该问题的一个清单。在mysql_upgrade 并重新启动后，一切正常。见：dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html

【解决方案9】：

mysql_upgrade 也对我有用：

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

问候，女士们。

【讨论】：

我确实需要重新启动 mysqld（mysql.server restart，因为我在 os x 上使用自制软件安装），所以这很有帮助。否则我得到一个关于 session_variables 结构错误的错误。
在 OS X 10.10.5 (Yosemite) 上与 Homebrew 的行为相同。进行升级还修复了尝试加载数据库时 Sequel Pro 1.1（内部版本 4499）中的崩溃。
Native table 'performance_schema'.'session_variables' has the wrong structure
如果您使用的是brew services，您可以使用brew services restart mysql 重新启动您的服务器。
这对我不起作用，正确答案由viq给出。仅需要启用节目兼容性。