说实话，每次看到有人对着终端敲mysqldump恢复命令的时候，我都觉得像是看一场微型手术。数据这玩意儿，平时没人当回事，一旦崩了，所有人都慌了神。mysqldump这个工具，备份的时候很简单，一个命令就跑完了，但恢复的时候，坑多到你怀疑人生。我见过太多人，备份文件倒是老老实实每天定时生成，结果真到恢复那天，要么字符集乱码，要么表结构对不上，要么直接卡死在半路上。所以今天这篇，咱们就好好聊聊mysqldump恢复数据库这件事，不扯虚的，全是实战里踩过的雷和绕过的坑。
先说说最基本的恢复姿势。假设你手里有一个用mysqldump导出的SQL文件，叫backup.sql，想把它恢复到某个数据库里。最直接的办法就是登录MySQL客户端，然后source一下。比如你先创建好目标数据库，use进去，再执行source /path/to/backup.sql。这个操作看着简单，但有个细节特别容易翻车——如果你没先use到正确的库，直接在默认库里source，那表就会被创建到别的地方去。更坑的是，有些版本的mysqldump导出时不会自动写CREATE DATABASE语句，你得手动建库。所以每次恢复前，我习惯先看一眼备份文件的前几行，确认它有没有带建库语句，再决定要不要提前建库。
再深入一层，很多人不知道mysqldump恢复是可以指定库名重定向的。比如你备份的是整个实例，但只想恢复其中某一个库，直接source整个文件的话，其他库的数据也会被写进去，搞不好就把线上数据覆盖了。这时候就得用到命令行重定向：mysql -u root -p 目标库名 < 备份文件.sql。这个操作会把SQL文件里的内容直接灌进指定的库里，但前提是备份文件里不能有USE语句，否则还是会跳库。所以更稳妥的做法是，先用grep或者sed把备份文件里的USE和CREATE DATABASE语句注释掉，再重定向进去。我有个同事当年就是没注意这个，把测试库的备份恢复到了生产库，整个周末都在加班回滚。
说到坑，字符集绝对是大魔王。很多mysqldump备份文件默认用的是utf8，但你的数据库可能用的是utf8mb4，或者更古老的latin1。恢复的时候，如果字符集对不上，中文直接变问号，或者干脆报错。我解决这个问题的方法很简单：在恢复命令里显式指定字符集。比如mysql --default-character-set=utf8mb4 -u root -p 目标库 < 备份.sql。这个参数会告诉客户端，在解析SQL文件时按什么编码去读。注意，这跟数据库本身的字符集设置是两回事，但能避免大部分乱码问题。另外，如果你备份时用了--set-charset参数，恢复时客户端会自动识别，但为了保险，我每次都会手动加上。
还有一个容易被忽视但致命的细节：大文件的恢复。一个几GB的SQL文件，直接用source命令恢复，中间一旦网络闪断或者终端超时，整个恢复过程就挂了，而且已经插入的数据可能还留着，导致重复主键冲突。我建议的做法是，用管道或者重定向的方式在后台执行，并且加上--force和--verbose参数。--force可以让MySQL忽略掉一些非致命错误继续往下跑，--verbose能实时打印进度，方便你判断是不是卡住了。更专业的做法是用pv命令监控管道流量，比如pv backup.sql | mysql -u root -p 目标库，这样你能看到每秒处理了多少数据，心里有底。
如果你恢复的是超大型数据库，比如几百GB的那种，直接用mysqldump恢复就是自找麻烦。这时候得考虑分片恢复。常见的手法有两种：一种是备份时用--tab参数把每个表导出成独立的SQL文件和txt数据文件，恢复时用mysqlimport批量导入；另一种是备份时用--where条件按时间或ID范围拆分成多个小文件，然后并发恢复。我见过最狠的操作，是写了个shell脚本，把备份文件按表分割成独立文件，然后用xargs开多个进程同时恢复，速度直接快了10倍。但要注意，并发恢复时得保证表之间没有外键依赖，否则锁冲突会让你欲哭无泪。
还有一个容易翻车的场景：跨版本恢复。比如你从MySQL 5.7备份的数据，要恢复到8.0的实例里。mysqldump导出的SQL文件里，很多语法在不同版本间是有差异的，比如5.7的某些字段类型在8.0已经被废弃，或者默认值的行为变了。我遇到过最离谱的一次，是把5.7的datetime默认值'00-00-00 00:00:00'恢复到8.0，结果直接报错，因为8.0默认启用了严格模式，不允许这种非法日期。解决办法是恢复前先检查MySQL的sqlmode，临时关掉严格模式，恢复完再改回来。或者更彻底点，用sed把备份文件里的非法日期替换成null。
聊聊恢复后的验证。很多人恢复完数据，看一眼表行数对得上就以为完事了。实际上，mysqldump恢复过程中可能因为各种原因跳过了一些数据，比如主键冲突、唯一索引重复、外键约束失败。我建议恢复完成后，立即跑一下CHECK TABLE，检查所有表的完整性。更靠谱的做法是，在恢复前对原库做一个简单的数据摘要，比如每个表的行数、某个关键字段的最大最小值，恢复后再对比一遍。我见过最惨的一次，是恢复后应用程序跑了一周才发现某个关联表缺了30%的数据，因为恢复时那个表因为外键约束被静默跳过了，但错误信息被日志淹没了。
说到底，mysqldump恢复数据库命令本身不复杂，复杂的是它背后那些你没想到的边界情况。每次恢复操作，我都当成一次小型灾难演练来对待。备份文件是你的一道防线，但如果你连恢复命令的细节都没吃透，那这道防线就跟纸糊的一样。下次你敲下那条恢复命令之前，不妨多花一分钟，想想字符集对不对、版本匹不匹配、有没有外键依赖、要不要先改sqlmode。这些细节，才是真正让数据安全落地的关键。
