MySQL的权限体系并不是简单的用户密码校验，而是由mysql系统库中的user、db、tables_priv、columns_priv和procs_priv等多张表共同构成。其中mysql.user表负责全局认证和全局权限，一旦被误修改，影响会立刻波及所有连接。出现这种情况时，不用急着卸载或初始化数据目录，先根据服务状态选择恢复路径，大部分误改都能在几分钟内修复。

一、先评估误修改的影响范围

常见误操作包括直接执行DELETE FROM mysql.user WHERE user='root'，或者把root的host改成不存在的网段，导致本地socket无法匹配；还有用UPDATE修改authentication_string但漏改plugin，使密码校验逻辑混乱。此时要先确定三件事：服务能否正常启动、root能否本地登录、是否还有其他管理员账号。如果mysqld能正常加载权限表，说明表没有损坏，只是授权数据异常；如果启动时报错类似“Table 'mysql.user' doesn't exist”，则属于表丢失或结构损坏，需要先恢复表结构。

可以用命令行测试本地socket连接：

mysql -u root -p -S /var/run/mysqld/mysqld.sock

如果提示Access denied for user 'root'@'localhost'，基本就是权限行不匹配的问题。然后查看错误日志：

tail -f /var/log/mysql/error.log

根据报错信息进一步判断，是plugin不存在、密码串格式不对，还是权限行缺失。这个阶段不要盲目重启或加参数，先收集足够的信息，再决定走标准SQL修复还是skip-grant-tables应急通道。

二、服务可登录时的恢复方式

如果还能用root或某个SUPER账号进入MySQL，优先使用标准SQL修复，而不是直接改系统表。操作前先备份现有mysql库，这样即使后续操作出错也能回滚。备份命令如下：

mysqldump -u root -p mysql user db tables_priv columns_priv procs_priv > mysql_grants_backup.sql

备份时注意不要只导出部分表，因为权限表之间有关联，备份完整一点更利于恢复。如果表已经损坏，备份可能会中断，可以先只导出正常表，剩下的通过权限重建补齐。

对于账号缺失或host错误，不要直接INSERT INTO mysql.user，因为MySQL 5.7和8.0的user表列很多，手工插入容易漏掉ssl_type、x509_issuer等列，还会导致密码编码不一致。推荐用CREATE USER重建，再用GRANT授权，例如：

CREATE USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'Str0ngPass!';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

MySQL 8.0默认使用caching_sha2_password，如果客户端较老，可改成mysql_native_password。但要注意plugin必须存在，否则认证仍然会失败。如果只是密码串被改乱，但账号存在，直接ALTER USER重置密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPass@123';

不能继续用UPDATE mysql.user SET authentication_string=PASSWORD('...')这种方式，因为PASSWORD()函数在MySQL 8.0已经移除，而且直接改列值不会正确处理plugin和密码加密。修改完成后执行FLUSH PRIVILEGES让权限表重新加载到内存。

三、所有账号都无法登录时用skip-grant-tables

如果root和所有管理员账号都无法连接，说明权限表内容已经影响到正常认证，但MySQL服务本身还能启动。此时需要采用跳过权限检查的应急模式。先正常停止服务：

systemctl stop mysql

然后以安全模式启动，最好同时禁用网络，防止外部连接利用无权限状态：

mysqld_safe --skip-grant-tables --skip-networking &

或者Windows下在my.ini的[mysqld]段临时加入skip-grant-tables，启动后再删除。这个模式下任何账号都可以无密码进入，所以必须用--skip-networking或防火墙限制来源IP。

进入后先不要急着UPDATE，因为skip-grant-tables下权限系统不会自动刷新，FLUSH PRIVILEGES是必须的操作。如果账号被删了，可以先插入一条最小可用行：

FLUSH PRIVILEGES;
INSERT INTO mysql.user (host, user, plugin, authentication_string, ssl_type)
VALUES ('localhost', 'root', 'mysql_native_password', '', '');
FLUSH PRIVILEGES;

这里把authentication_string留空是为了先让账号无密码登录，后面再用ALTER USER设置正式密码。如果直接写入加密串，容易因为函数不存在或算法不匹配导致无法使用。如果只是root的host写错：

UPDATE mysql.user SET host = 'localhost' WHERE user = 'root' AND host <> 'localhost';
FLUSH PRIVILEGES;

要注意，如果同时存在'root'@'%'和'root'@'localhost'，MySQL会优先精确匹配。修改后先退出，正常重启服务，再用root无密码或新密码登录，并通过ALTER USER设置复杂密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'FinalPass@456';

四、恢复后的验证与日常预防

恢复之后不能只测试root登录，还要检查业务账号的权限是否完整，尤其是mysql.db表中的库级授权、tables_priv中的表级权限。建议执行：

SHOW GRANTS FOR 'appuser'@'%';
SELECT host, db, user FROM mysql.db WHERE user = 'appuser';

确认之前被删掉的库权限已经恢复。如果是从备份文件中找回，需要对比备份时间点和当前的授权差异，避免遗漏新增账号。

日常管理账号时，优先使用CREATE USER、ALTER USER、GRANT、REVOKE等标准语句，不要直接对mysql.user、mysql.db做DELETE或UPDATE。如果必须批量调整，先在一个测试实例上验证SQL，并且在执行前备份mysql库：

mysqldump -u root -p --routines --events mysql > mysql_full_$(date +%F).sql

这样即使误操作，也能快速恢复到最近的时间点。最后提醒，--skip-grant-tables只能作为临时抢救通道，恢复后必须确认配置文件中没有残留该参数，否则数据库会长期处于无认证状态。生产环境还应配合操作系统防火墙、MySQL的bind-address和max_connect_errors等参数，降低被恶意利用的风险。权限表修复完成后做一个完整登录回归，包括本地socket、TCP、远程账号和只读账号，确保没有遗留问题。