MySQL报错ER_MISSING_ACL_SYSTEM_TABLE导致权限问题，远程帮忙修复方案分享

（来源：CSDN博客《一次MySQL权限表损坏的修复经历》）前几天，一个朋友的线上MySQL数据库突然出了怪事，本来运行得好好的，突然所有用户，包括root用户，都几乎没法正常操作了，具体表现是，登录数据库后，执行像show databases;这样的简单命令，都会弹出一个非常吓人的错误：ERROR 1146 (42S02): Table 'mysql.host' doesn't exist，紧接着，尝试任何赋予权限的操作（比如GRANT语句）都会失败，并伴随着ER_MISSING_ACL_SYSTEM_TABLE这个错误代码。

（来源：MySQL官方文档对ER_MISSING_ACL_SYSTEM_TABLE的解释）这个错误的核心意思是，MySQL服务器找不到它赖以生存的权限系统表了，MySQL用它来管理用户账号、密码、以及每个用户能对哪个数据库、哪张表进行什么操作，这些表都存放在一个叫mysql的系统数据库中，主要包括user、db、host、tables_priv、columns_priv等几张表，一旦这些表丢失或者损坏，MySQL就无法验证用户身份和权限，整个数据库的访问控制就乱套了。

当时的情况非常紧急,因为应用已经无法连接数据库，业务处于停滞状态，由于是远程协助，我们没法直接接触服务器，只能通过朋友在服务器上执行命令，然后他把屏幕截图或者输出结果发给我，这种远程帮忙修复，沟通和操作的准确性至关重要。

第一步：保持冷静，确认问题

我让朋友登录MySQL服务器,并尝试进入mysql数据库，然后查看表是否存在。 他执行的命令是：

mysql -u root -p

输入密码后（幸运的是root还能本地登录），

use mysql;
show tables;

（来源：根据朋友提供的操作反馈）反馈的结果证实了我们的猜测：show tables命令返回为空，或者只显示了很少的几个表，关键的user、host等表果然不见了，这说明mysql数据库中的权限表确实发生了丢失，丢失的原因可能多种多样，比如磁盘空间不足导致写入失败、非正常关机、或者某些极端情况下误删了系统表。

第二步：停止MySQL服务，防止数据覆盖

在确认问题后,我立即让朋友停止了MySQL服务，这是非常关键的一步，因为如果MySQL服务还在运行，它可能会尝试写入一些数据，如果权限表文件已经丢失，这些写入行为可能导致更复杂的问题，或者覆盖掉一些可能恢复的数据。 停止服务的命令根据操作系统有所不同，他使用的是CentOS系统，所以执行：

systemctl stop mysqld

第三步：寻找备份（最理想的方案）

停下来之后,我们首先考虑的是从备份恢复，这是最快、最安全、风险最低的方案，我问他最近有没有做数据库的完整备份，特别是mysql数据库的备份，他检查后发现，虽然有业务数据的定期备份，但恰好没有单独备份系统库mysql，这个方案行不通了。

第四步：使用mysql_install_db重新初始化系统表

（来源：MySQL官方手册中关于mysql_install_db的说明）既然没有备份，我们只能尝试重建这些丢失的系统表，MySQL提供了一个工具叫mysql_install_db（在MySQL 5.7版本中）或mysqld --initialize（在MySQL 5.7及更高版本中），它的一个重要作用就是初始化数据目录，并创建必需的mysql系统数据库及其中的表。

我让他先备份一下当前整个MySQL的数据目录（以防万一）：

tar -czf /tmp/mysql_data_backup.tar.gz /var/lib/mysql

我们使用mysql_install_db工具来重新生成系统表，需要注意的是，这个操作会覆盖现有的mysql数据库，但由于我们已经确认它已经损坏/丢失，所以这是必要的，我让他执行：

mysql_install_db --user=mysql --datadir=/var/lib/mysql

这里的--user指定运行MySQL服务的系统用户（通常是mysql），--datadir指定MySQL数据目录的路径（通常是/var/lib/mysql，具体位置可以通过查看原my.cnf配置文件确认）。

执行这个命令后,工具会在数据目录中重新创建mysql系统数据库和所有必要的表。

第五步：恢复权限表数据（最棘手的部分）

系统表是重建了,但一个大问题来了：新建的表是空的，没有任何用户账号信息，这意味着连root用户都没有设置密码，任何人都可以无密码登录，并且拥有最高权限，这比之前的问题更严重。

我们需要恢复原来的用户和权限数据,这时，我们想到了MySQL的日志，我让他查看MySQL的错误日志（通常位于/var/log/mysqld.log或数据目录下的hostname.err文件），期望能找到一些线索，幸运的是，在错误日志中，我们看到了MySQL在崩溃前记录的一些SQL语句，其中包括了创建用户和授权语句的片段，但这太零散了，无法直接使用。

（来源：朋友回忆的操作历史）这时，朋友想起来他曾经在出现问题前，大概一周左右，执行过mysqldump备份了整个mysql数据库，这个备份文件还在！这简直是救命稻草，我们找到了一个名为mysql_backup.sql的文件。

我们计划将这个备份文件导入到新初始化的mysql数据库中。

1. 启动MySQL服务（此时root无密码）：

   systemctl start mysqld

2. 无密码登录MySQL：

   mysql -u root

3. 将备份的mysql数据库导入：

   source /path/to/mysql_backup.sql;

   这个过程可能会遇到一些错误,比如某些表已经存在（因为刚被初始化创建），我们选择的是强制覆盖，所以在导入前，他先删除了新初始化的mysql数据库（DROP DATABASE mysql;），然后重新创建（CREATE DATABASE mysql;），再使用use mysql;和source命令导入，这样确保了是完全的恢复。

第六步：重置root密码并验证权限

导入完成后,为了安全起见，我让他立即给root用户设置了一个新密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewStrongPassword123!';

重启MySQL服务使所有更改生效,然后分别用root账号和业务账号测试登录和执行操作，确认所有权限都已经恢复正常。

systemctl restart mysqld

远程修复的总结与反思

这次远程帮忙修复ER_MISSING_ACL_SYSTEM_TABLE错误，虽然过程紧张，但最终有惊无险，核心教训有几点：

1. 备份是生命线：一定要定期备份，而且不能只备份业务数据，系统库mysql的备份同样至关重要，这次幸亏有一个一周前的mysql库备份。
2. mysql_install_db是利器：在系统表丢失时，这个工具是重建基础结构的标准方法。
3. 操作前先备份现状：即使在修复过程中，对当前问题目录进行打包备份也是一个好习惯，万一新操作导致更糟的情况，还有回滚的余地。
4. 远程协作要清晰：每一步指令都要非常明确，并且要求对方反馈确切的执行结果或截图，避免因理解偏差导致误操作。

通过这次经历,我们也意识到，数据库的稳定运行不仅依赖于平时的优化，更依赖于一套完善的备份和灾难恢复预案。