最直接有效的恢复方式是从备份中还原 mysql 系统数据库——因其包含所有用户、权限、角色等完整元数据，且无法通过 grant 语句完全逆向重建（如密码哈希、账户锁定状态、资源限制等）。
MySQL 权限表被误修改后，最直接有效的恢复方式是**从备份中还原 mysql 系统数据库**——因为所有用户、权限、角色信息都存在其中，且无法通过 GRANT 语句完全逆向重建（比如密码哈希、账户锁定状态、资源限制等元数据会丢失）。
确认是否真的丢了权限，还是只是连接不上
很多“权限没了”的问题其实不是权限表损坏，而是：
-
root@localhost账户被删或密码重置失败，导致无法登录； - 误删了
mysql.user表中的默认行（如空用户、debian-sys-maint），但 MySQL 仍能启动； - 只改了某张表的权限（如
mysql.db），但mysql.user还在，只是全局权限不足。
先用安全模式验证：停掉 MySQL，加 --skip-grant-tables --skip-networking 启动，再连进去查 select host, user, authentication_string FROM mysql.user;。如果能查出记录，说明表结构和数据还在，只是权限逻辑失效。
没有备份时，临时救急：重建 root 并重载权限
若确认 mysql.user 表被清空或关键行丢失，又无备份，只能手动补基础账户。注意：这不等于恢复原始权限，只是让服务可用：
- 必须在
--skip-grant-tables模式下操作，否则INSERT/UPDATE会被拒绝； - MySQL 5.7+ 的
authentication_string字段必须填哈希值，不能直接写明文密码（可用SELECT PASSWORD('123');或更稳妥的SELECT SHA2('123',256);配合插件类型设置）； - 务必补全
plugin字段（常见为caching_sha2_password或mysql_native_password），否则登录时报Plugin caching_sha2_password could not be loaded； - 执行完要运行
FLUSH PRIVILEGES;，否则更改不生效； - 别忘了删掉
--skip-grant-tables后重启，否则所有用户免密可登。
从 mysqldump 备份恢复 mysql 库的实操要点
这是唯一能真正还原权限状态的方式，但有几个关键细节常被忽略：
- 备份必须包含
mysql库的完整表（user,db,tables_priv,procs_priv,role_edges,default_roles等），且mysqldump用了--single-transaction或--lock-tables=false，否则可能导出不一致快照； - 恢复前必须停掉 MySQL 或确保无其他连接在读写
mysql库，否则DROP TABLE会失败或引发崩溃； - 不能用
mysql -u root -p mysql 直接导入，因为备份里含 <code>CREATE database和USE mysql，而mysql库是系统库，需显式指定目标库：mysql -u root -p --force ； - 如果备份来自不同版本（如 5.7 → 8.0），
mysql.role_edges等新表可能缺失，需先运行mysql_upgrade（8.0.16+ 已废弃，改用mysqld --upgrade）。
权限恢复最难的点不在 SQL 操作本身，而在于你永远不知道哪一行 host + user 组合曾被设过 MAX_QUERIES_PER_HOUR 10，或者某个角色是否被 require X509 绑定——这些细节能让应用突然报错，却查不到日志源头。