MySQL 8.4 跨大版本升级后「ERROR 1130 + 无法本地登录 + 插件缺失」连环故障的深度修复

一、问题背景

最近我将一台 Windows 服务器上的 MySQL 数据库升级到了最新的8.4.8版本。升级过程看似顺利，然而当我尝试从远程客户端用 root 账户连接时，却遭遇了经典的ERROR 1130 (HY000): Host 'xxx' is not allowed to connect to this MySQL server。更诡异的是，当我直接登录服务器本机，使用mysql -u root -p也无法进入，同样提示权限或认证错误。于是，一场深入系统表、跨越多个版本遗留问题的修复之旅就此展开。

必须要说明的是，本篇博客为AI创作，作者大致浏览没发现问题后发布。全程为本地操作，不涉及远程访问。问题为本人本地连接数据库出现1130的错误，参考其它博客解决问题时，往往卡在第一步，登录。本人root账户在登录时同样出现1130错误，且之前试过重装MySQL数据库，但当时可以正常链接，后面链接又出现同样的1130问题，因此决定尝试彻底解决。注意：所有涉及到的文件路径都应该换成自己的文件路径。

二、错误全景回顾

在修复过程中，我依次遇到了下列错误，它们环环相扣，暴露了数据库升级过程中的深层损伤：

1. 远程连接报错：ERROR 1130– root 账户不允许从远程主机连接。

2. 本地登录失败：尽管我有 root 密码，但本地也无法登录，最终定位到认证插件和系统表损坏。

3. 安全模式启动失败：Can't create test file ... datadir ... No such file or directory– 数据目录路径错误。

4. 安全模式连接受阻：ERROR 2003 (10061)– 在 Windows 上未指定共享内存或命名管道，导致 MySQL 进程拒绝本地连接。

5. 协议参数错误：mysql客户端将共享内存协议识别为MEMORY而非shared-memory。

6. 系统表引擎异常：ERROR 1726: Storage engine 'MyISAM' does not support system tables. [mysql.user]以及后续的[mysql.db]。

7. 缺失内部用户：ERROR 1449: The user specified as a definer ('mysql.infoschema'@'localhost') does not exist。

8. 系统表列数不匹配：ERROR 1805: Column count of mysql.user is wrong. Expected 51, found 42. The table is probably corrupted。

9. 认证插件未加载：ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded。

这些问题最终都指向同一个根源：从 MySQL 5.x 直接升级到 8.4，系统数据库（mysql库）的表结构、存储引擎、内部用户和认证插件未能自动完成兼容性迁移。

三、根本原因深度剖析

MySQL 8.4 引入了多项重大变化：

• 系统表引擎必须为 InnoDB（包括user,db,tables_priv等），旧版 MyISAM 不再被支持。

• 内部新增了多个系统用户，如'mysql.infoschema'@'localhost'、'mysql.session'@'localhost'等，它们是information_schema视图的定义者。

• 用户认证默认使用caching_sha2_password插件，而旧版常用mysql_native_password，8.4 中后者默认未加载。

• mysql.user表结构从 42 列扩展到 51 列，用于支持更细粒度的权限管理。

我的数据库本体文件（数据目录）是从 MySQL 5.x 时代保留下来的，虽然通过升级程序将数据文件表面升级，但mysql系统库的表结构、引擎和必要组件未得到完整升级，导致一系列连锁反应。

四、详细解决步骤记录

以下所有操作均在Windows 系统、以管理员身份运行的 PowerShell中执行，MySQL 8.4.8 安装于C:\Program Files\MySQL\MySQL Server 8.4\，数据目录为C:\ProgramData\MySQL\MySQL Server 8.4\Data\。（管理员身份PowerShellwin+x后选择终端管理员）

4.1 准备环境：确认服务名与数据目录

• 查看 MySQL 服务名：sc query state= all | findstr /i "mysql"，记为MySQL84。

• 查看数据目录：mysqld --verbose --help | findstr "datadir"或直接查看服务属性中的配置文件路径，找到datadir。

4.2 启动安全模式（跳过权限）的正确姿势

停止正常服务：net stop MySQL84（这步也可以直接搜索服务，点进去找到MySQLXX后右键停止）

以安全模式启动，必须指定数据目录、共享内存协议，并禁止网络连接：

powershell

cd "C:\Program Files\MySQL\MySQL Server 8.4\bin" .\mysqld --skip-grant-tables --skip-networking --shared-memory --datadir="C:\ProgramData\MySQL\MySQL Server 8.4\Data" --console

保持窗口打开，直到看到ready for connections。

4.3 连接安全模式实例

新开一个管理员终端，使用共享内存协议连接：

powershell

cd "C:\Program Files\MySQL\MySQL Server 8.4\bin" .\mysql -u root --protocol=MEMORY

注意：MySQL 8.4 客户端中，共享内存协议选项为MEMORY，不是shared-memory。

4.4 修复系统表引擎与结构

在mysql>提示符下，逐步执行以下修复：

1. 强制将所有权限表转为 InnoDB：

sql

SET SESSION FOREIGN_KEY_CHECKS=0; ALTER TABLE mysql.user ENGINE=InnoDB; ALTER TABLE mysql.db ENGINE=InnoDB; ALTER TABLE mysql.tables_priv ENGINE=InnoDB; ALTER TABLE mysql.columns_priv ENGINE=InnoDB; ALTER TABLE mysql.procs_priv ENGINE=InnoDB; ALTER TABLE mysql.proxies_priv ENGINE=InnoDB; ALTER TABLE mysql.global_grants ENGINE=InnoDB; ALTER TABLE mysql.password_history ENGINE=InnoDB; ALTER TABLE mysql.role_edges ENGINE=InnoDB; ALTER TABLE mysql.default_roles ENGINE=InnoDB; SET SESSION FOREIGN_KEY_CHECKS=1;

1. 创建缺失的内部系统用户：

sql

CREATE USER 'mysql.infoschema'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'Temp@1234' ACCOUNT LOCK; FLUSH PRIVILEGES;

此时可能因列数不对而失败（错误 1805），这是下一步要解决的。

4.5 强制升级系统表结构

由于手动修改列数极其危险，我们使用 MySQL 内置的--upgrade=FORCE功能完成系统表的自动化升级。

1. 关闭当前安全模式实例（Ctrl + C）。

2. 以升级模式启动必须带--datadir：

powershell

.\mysqld --upgrade=FORCE --datadir="C:\ProgramData\MySQL\MySQL Server 8.4\Data" --console

1. 观察日志，出现Server upgrade from '80408' to '80408' completed.以及ready for connections后，按Ctrl + C停止进程。

该过程会自动修正mysql.user列数、所有系统表的引擎和结构，并补齐缺失的内部用户。

4.6 再次进入安全模式，修复认证插件

强制升级后，系统表结构已正确，但root用户的认证插件可能仍为mysql_native_password，导致登录时报告Plugin not loaded。

1. 重新启动安全模式（带--skip-grant-tables等参数）。

2. 连接后执行：

sql

FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '你的密码'; ALTER USER 'root'@'%' IDENTIFIED WITH caching_sha2_password BY '你的密码'; FLUSH PRIVILEGES;

注意：此处的BY '密码'需要填写已知的当前密码，它会用新插件重新生成哈希，密码不变。如果忘记密码，可先重置。

1. 退出并关闭安全模式。

4.7 恢复正常服务与会话

powershell

net start MySQL84 .\mysql -u root -p

输入密码，成功进入mysql>提示符，问题彻底解决。

五、善后检查与安全加固

登录后执行以下检查，确保系统完全健康：

sql

-- 所有系统表引擎应为 InnoDB SELECT DISTINCT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='mysql'; -- root 用户插件应为 caching_sha2_password SELECT user, host, plugin FROM mysql.user WHERE user='root'; -- 系统内部用户应存在 SELECT user, host FROM mysql.user WHERE user LIKE 'mysql.%';

建议立即将弱密码更改为强密码：

sql

ALTER USER 'root'@'localhost' IDENTIFIED BY '复杂密码'; ALTER USER 'root'@'%' IDENTIFIED BY '复杂密码'; FLUSH PRIVILEGES;

如果仍需远程连接 root，确保'root'@'%'存在或创建具体 IP 的用户，并检查防火墙/安全组放行 3306 端口。

六、经验与总结

1. 不要跨大版本直接覆盖数据目录升级。最佳实践是使用mysqldump进行逻辑备份与恢复，或者严格遵循官方升级程序，并每次执行mysql_upgrade（8.0 后集成到服务器--upgrade选项）。

2. MySQL 8.4 移除mysql_native_password插件，老旧应用需更新客户端或手动加载（不推荐）。账户密码应迁移到caching_sha2_password。

3. Windows 下安全模式启动必须指定--shared-memory，否则可能因无可用协议而退出；客户端连接需使用--protocol=MEMORY。

4. 数据目录参数不能漏：任何手动mysqld启动，都应显式指定--datadir，避免找不到数据文件。

5. 遇到连环错误时，从根源解决：本例中--upgrade=FORCE解决了表结构、列数和内部用户等一大半问题，再辅以引擎和插件的定点修复，最终完美收官。

这次故障修复历时数小时，踩过的坑可谓丰富。希望这一篇详实的记录能为遇到类似问题的同学们提供一份捷径参考。如果你也在升级 MySQL 8.4 途中遭遇了 ERROR 1130、系统表损坏等诡异问题，相信本文能帮到你。