误删mysql系统库表后不可用普通备份恢复，因mysqldump默认跳过mysql库且权限表强耦合实例状态；必须停服、保留现场、优先用物理备份还原，无备份时需初始化重建并手动补权。
误删系统元数据（比如 mysql 库下的 user、db、tables_priv 等表）后，不能直接用普通业务备份恢复——因为标准 mysqldump 默认会跳过 mysql 系统库，且权限表结构与数据强耦合于 MySQL 实例状态。必须用专门方式处理。
为什么 mysqldump 备份通常不包含 mysql 库
默认情况下，mysqldump --all-databases 会排除 mysql、information_schema、performance_schema 和 sys 这几个系统库。这是出于安全和一致性考虑：权限表的导出/导入容易引发认证失败、权限错乱甚至实例无法启动。
- 检查你的备份 SQL 文件是否真包含
mysql库：用grep -n "CREATE TABLE.*user" backup.sql快速确认 - 若无，说明该备份不可用于恢复元数据，需切换方案
- 即使有，也需验证其导出时是否加了
--skip-triggers --skip-routines --skip-events等参数——这些可能让触发器或存储过程缺失，导致权限行为异常
恢复 mysql 库前必须停服并备份当前残留状态
误删后继续运行 MySQL 会导致新用户登录、权限变更等操作写入内存或日志，进一步污染现场。必须立刻停止服务，并保留原始数据目录作为“证据”。
- 执行
systemctl stop mysqld（或kill -15 $(cat /var/run/mysqld/mysqld.pid)） - 对当前
/var/lib/mysql/mysql/目录做原子快照：cp -a /var/lib/mysql/mysql /var/lib/mysql/mysql.bak_$(date +%s) - 不要直接删除或覆盖原目录——哪怕它看起来是空的，
ibdata1或ib_logfile*中仍可能存有未刷盘的 undo 记录
从物理备份还原 mysql 库最可靠
只有物理备份（如 Percona XtraBackup、rsync 全量拷贝）能完整保留 mysql 库的文件级一致性。逻辑备份恢复 mysql 库极易因字符集、SQL mode、GTID 状态等差异失败。
- 确认物理备份中存在
/backup/path/mysql/子目录，且包含user.MYD、user.MYI（MyISAM）或user.ibd+user.frm（InnoDB）等文件 - 停服后，清空当前
/var/lib/mysql/mysql/，再将备份中的mysql/目录整体复制过去 - 特别注意文件权限：
chown -R mysql:mysql /var/lib/mysql/mysql，否则启动报错Can't open the mysql.plugin table - 启动前先校验：
mysqld --validate-config；启动时加--skip-grant-tables可绕过权限检查，但仅限紧急诊断，不可长期启用
没有物理备份时，用初始化+手动补权的兜底方案
如果既无物理备份，又没导出过 mysql 库，只能重建系统库结构，再人工恢复关键权限。这不是“恢复”，而是“重建信任链”。
- 用
mysqld --initialize --user=mysql生成全新mysql库（会重置 root 密码，记录在 error log 中） - 启动后立即执行：
mysql -u root -p -e "CREATE USER 'admin'@'%' IDENTIFIED BY 'xxx'; GRANT ALL ON *.* TO 'admin'@'%' WITH GRANT OPTION;" - 从应用配置、部署脚本或 Git 历史中找回各业务账号的
CREATE USER和GRANT语句，逐条执行 - 切勿用
INSERT INTO mysql.user直接写表——密码哈希、plugin 字段格式极易出错，导致账号不可用
真正危险的不是“怎么恢复”，而是误删后还继续执行 FLUSH PRIVILEGES 或新建用户——这会让内存中损坏的权限状态落盘，彻底堵死回退路径。所有操作务必在离线状态下完成，每一步都留痕。
