新手应从mysqldump单库备份和mysql命令恢复起步，用--single-transaction避免锁表，导出前查字符集并加--default-character-set=utf8mb4，恢复前用head/tail检查sql文件头尾，每步验证输出。
适合新手，但必须从最简场景起步，跳过图形工具和自动化脚本，直接用 mysqldump 和 mysql 命令练手——这是唯一能让你看清备份恢复本质的路径。
只用 mysqldump 备份单库，别碰全库或通配符
新手最容易在备份阶段就出错：用 mysqldump -A 导出所有库，结果发现 information_schema 或 performance_schema 报错、导出文件里混入大量警告、恢复时权限表冲突。这些不是你的错，是设计如此。
- 只用
mysqldump -u root -p mydb > mydb.sql，明确指定一个业务库名 - 加
--single-transaction（InnoDB 表适用），避免锁表；不用--lock-all-tables，它会阻塞写入 - 不加
--routines或--events，存储过程和事件默认不导出，省去权限和兼容性麻烦 - 导出前先确认字符集：
SHOW CREATE DATABASE mydb;，若为utf8mb4，导出命令末尾加--default-character-set=utf8mb4
恢复前必须手动检查 SQL 文件头三行
很多恢复失败不是命令写错，而是没看文件内容。比如导出时用了 -p 但输错密码，mysqldump 会静默生成空文件或只含错误提示的文本；又或者导出目标库不存在，文件开头是 ERROR 1049 (42000) 而非 CREATE DATABASE。
- 用
head -n 3 mydb.sql看前三行：正常应有CREATE DATABASE或USE mydb，否则停止恢复 - 用
tail -n 5 mydb.sql看末尾：应以UNLOCK TABLES;或COMMIT;结束，而非ERROR或乱码 - 恢复命令严格用
mysql -u root -p mydb ，不要用 <code>source命令进 MySQL 再执行，容易因编码或分号解析出错
遇到 “Unknown collation: ‘utf8mb4_0900_ai_ci’” 就换导入方式
这是 MySQL 8.0 默认排序规则，而你本地可能是 5.7 或旧客户端，mysql 命令行工具版本太低时会直接报错退出，且不提示具体哪一行出问题。
- 先查本地客户端版本：
mysql --version，若低于 8.0.11，升级或换用同版本服务端的客户端 - 临时绕过：用
sed 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' mydb.sql > mydb_fixed.sql替换排序规则（仅限测试环境） - 更稳妥做法：在目标库创建时显式指定兼容排序规则，例如
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，再导入
备份恢复真正难的不是命令本身，而是你得习惯“每一步都验证输出”。比如导完立刻 ls -lh mydb.sql 看大小，不是 0 字节；恢复后立刻 mysql -u root -p -e "SELECT COUNT(*) FROM mydb.mytable;" 查一行数。这些动作看起来琐碎，却是区分“以为恢复成功”和“确实恢复成功”的唯一标尺。
