mysqldump 备份 mysql 库必须加 --single-transaction 吗？
不是必须，但不加就很可能出错或不一致。因为 mysql 库里的表（比如 user、db、tables_priv）在备份过程中可能被其他管理员修改，导致导出的权限状态和实际运行时不匹配。
使用 --single-transaction 能让 mysqldump 在事务快照中读取这些表——前提是所有表都是 InnoDB 引擎。而 mysql 库默认从 MySQL 8.0 起已全部转为 InnoDB，5.7 及更早版本里部分表（如 proc、event）仍是 MyISAM，此时该参数无效，会自动退化为加全局读锁（FLUSH TABLES WITH READ LOCK），阻塞写操作。
- MySQL 8.0+：推荐加
--single-transaction，安全且不锁库 - MySQL 5.7 及更早：检查引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql';；若存在 MyISAM 表，加--lock-all-tables比--single-transaction更可靠 - 无论如何，避免只用
mysqldump mysql不带任何锁或事务控制——权限备份一旦错位，恢复后可能连root都无法登录
备份时要不要跳过 sys、performance_schema、information_schema？
要跳过。这三个库不是真实数据目录里的物理库，而是运行时动态生成的视图或内存结构，不能也不该用 mysqldump 导出。
information_schema 和 performance_schema 完全不可写，dump 会报错或返回空内容；sys 是基于 performance_schema 的视图集合，同样无备份价值。强行包含只会拖慢速度、制造虚假备份文件。
- 正确命令片段：
mysqldump --all-databases --ignore-database=sys --ignore-database=performance_schema --ignore-database=information_schema - 注意：
--all-databases默认包含mysql，所以无需额外写mysql；但如果你是单独 dumpmysql，就别再手动加上那三个库名 - 某些自动化脚本会误把
sys当成普通库一并 dump，结果恢复时报Unknown table 'sys.x$host_summary'类错误——其实根本没这个表，只是视图
恢复 mysql 库前为什么必须停掉 MySQL 并清空原 mysql 目录？
因为权限表（user、global_grants 等）是服务启动时由 mysqld 直接加载进内存的，不是靠 SQL 执行生效的。直接用 mysql 命令导入 SQL 文件，只能改磁盘上的 .ibd 文件，但 mysqld 还按旧缓存运行，甚至可能因元数据校验失败拒绝启动。
真正的恢复流程是：停服务 → 替换 datadir/mysql/ 下的文件（或用 mysql_upgrade 配合初始化）→ 再启服务。否则你会遇到“明明导入了新 root 密码，却还是连不上”的情况。
- 不要尝试用
mysql -u root -p mysql 恢复核心库——它只执行 DML，不重载权限缓存 - MySQL 8.0+ 支持
--init-file启动参数执行初始化 SQL，但仅适用于新增账号等简单场景，不替代完整库恢复 - 如果只是想更新个别权限，用
GRANT/CREATE USER语句在线操作更安全；整库恢复属于灾备动作，必须走文件层
备份文件里含明文密码？mysql.user 表字段加密方式影响恢复吗？
不影响恢复，但影响安全性。MySQL 8.0 默认用 caching_sha2_password 加密存储密码，5.7 用 mysql_native_password；备份文件里存的是哈希值（如 *AAB3E285149C019060B35929190E6924F3023789），不是明文，所以导出文件本身不泄露密码。
真正要注意的是：如果备份时用了 --skip-triggers 或 --skip-routines，而你的 mysql 库里有自定义函数或触发器（极少见但存在），它们不会被包含，恢复后可能缺失权限逻辑。
- 确认密码字段是否加密：
SELECT host,user,plugin,authentication_string FROM mysql.user;；若plugin是caching_sha2_password，说明已启用强加密 - 备份命令建议显式加上
--routines --triggers --events，哪怕mysql库通常不含这些，也防未来升级引入 - 别用文本编辑器打开备份 SQL 查看密码——看到的只是哈希，徒增困惑；真要验证，用
mysqlcheck --check mysql.user
mysql 库最易被忽略的点，是以为“只要 dump 出来就能恢复”，其实它和普通业务库完全不同：它既是数据，也是配置，更是 mysqld 的运行契约。一次不完整的备份，可能让整个实例在恢复后变成“有库无权、有权无用户”的黑盒。 
