说实话，刚入行的时候，我对 MySQL 命令行恢复数据库这事完全没有概念。那时候公司运维说“库崩了，你自己看着办”，我盯着黑乎乎的终端窗口，手都在抖。后来被逼着翻了三天官方文档，又熬了几个通宵，总算把流程摸清楚了。现在回头看，这玩意儿其实没那么玄乎，但确实有几个坑，踩一个就够你喝一壶的。
先说说最基础的操作：用 mysql 命令恢复。假设你手里有个备份文件，比如 backup.sql，那直接在命令行敲 就行。这行命令的意思是，用 root 用户登录，输入密码，然后把 backup.sql 里的数据全部导入到指定的数据库里。注意，这里有个关键点：你得先确保目标数据库存在。如果不存在，系统会直接报错，提示 “Unknown database”。所以恢复之前，最好先登录 MySQL，用 建好库，再执行导入。很多新手就是卡在这一步，以为备份文件会自动创建数据库，结果搞半天才发现白忙。
还有个容易忽略的细节：字符集问题。我见过一个同事恢复中文数据表，结果导入后全是乱码。原因很简单，备份文件是 UTF-8 编码，但 MySQL 客户端默认是 latin1。解决办法也直接：在导入时加上字符集参数，比如 。或者更稳妥的做法，是在备份时就指定字符集，用 。这招能省掉后续一堆麻烦。
再说说更复杂的情况：大文件恢复。你手里有个 5 GB 的备份文件，直接 ，等了一个小时还没反应，终端里什么提示都没有，这种感觉就像在等一锅永远不开的水。这时候你得学会拆分任务。可以用 或 把文件按表拆分，例如 ，然后分批导入。或者直接用 ，这样可以看到每条语句的执行进度，心里踏实点。还有个土办法，用 监控管道流量：，至少能看到传输速度，不至于干着急。
如果你使用的是 MySQL 5.7 以上的版本，还得注意一个坑：GTID（全局事务标识符）模式。有些备份文件里带了 GTID 信息，导入时如果目标库的 GTID 模式设置不一致，会报错 “ERROR 1785”。解决办法有两种：要么在导入时加上 参数，要么在 MySQL 配置文件里把 调整为一致。我建议新手直接用第一种，简单粗暴。另外，恢复过程中如果遇到外键约束失败，也别慌，先执行 ，导入完再恢复为 1。这招能跳过很多校验错误，尤其适合恢复多个有依赖关系的表。
还有个实战场景：远程恢复。有时候手头只有一台远程服务器，备份文件在本地，怎么搞？第一种方法是直接 ssh 管道：，前提是远程主机已经配置好免密登录。第二种是先用 scp 把文件传过去：，然后远程登录再导入。我偏向第一种，省时间，但要注意网络稳定性，万一断开，恢复就中断了，还得从头来。可以考虑用 或 让任务在后台跑，例如 ，这样就能安心去喝咖啡了。
说个教训：别忘了检查恢复结果。很多人导入完就以为万事大吉，结果第二天发现某个表少了 100 条数据。正确的做法是，恢复后立刻执行 ，跟备份时的记录数对一下，或者用 之类的工具做表结构比对。我习惯在恢复脚本里加一行 ，至少能知道什么时候干完的。还有，如果使用的是 InnoDB 引擎，恢复后最好执行 ，确保索引没有损坏。别嫌麻烦，生产环境里，一个小错误就能让你整个周末泡汤。
说到底，MySQL 命令行恢复这事，考验的不是技术，而是耐心和细节。你不需要成为 DBA，但得学会怎么跟黑框框打交道。备份文件是你的救命稻草，但前提是你知道怎么正确把它拉上岸。每次恢复完，我建议花 10 分钟写个复盘笔记，记下这次用了什么命令、踩了哪些坑、怎么解决的。下次再遇到类似场景，你就不再是那个对着终端发抖的新手了。毕竟，在 IT 这行里，经验都是用错误堆出来的。
