数据库导出命令；3个参数最容易翻车

数据库导出命令这东西，敲完回车看着挺顺的，日志一行行滚，你以为完事了。等到真拿这份 dump 去恢复的时候才发现——表建了、数据进去了，可中文全是问号，或者少了最近半小时的订单。翻车的从来不是整条命令，是里面那两三个你压根没留意的参数，下面挨个说。

数据库导出命令里最不显眼的字符集参数

先说这个，因为它最阴。mysqldump 默认是按客户端那边的字符集走的，你在一台 UTF-8 的机器上导出，拷到另一套环境再灌，多半没事；可要是中间经了一台老机器，或者你的库本身有 latin1 的老表，那一串乱码就能让你怀疑人生。我自己的习惯是导出的时候显式带上 –default-character-set=utf8mb4，别指望环境替你决定。多花那几个字节的输入成本，能换来一次不返工的恢复。不过这里有个容易忽略的点：字符集对了不代表排序规则也对，utf8mb4_general_ci 和 utf8mb4_0900_ai_ci 在某些版本间导过去之后，索引的行为会有细微差别，一般场景无所谓，你要是做唯一性校验比较多的业务，恢复完顺手看一眼表结构比较稳妥。

锁表：不加它快，加了它慢

–single-transaction 这个参数被讲烂了，但真正理解它为什么重要的人不多。它是靠一个可重复读的事务来保证导出的数据是一致的，代价是导出期间别人还能写，你的 dump 里看到的是一瞬间的快照。反过来，如果你不加它，默认那套加锁逻辑在 MyISAM 表上会让整张表只读，业务那边立刻就卡。所以参数的选择不是快慢问题，是你到底愿意让谁受委屈。有一点得提：–single-transaction 只对 InnoDB 有效，你要是库里还混着 MyISAM 的老表，它不保证。混着来的库，我一般是先查一下引擎分布再决定，别一把梭。

顺带说个反常识的。有人以为加了 –single-transaction 就等于绝对一致，其实它和 –lock-tables 是互斥的，两个都写上去，后面的会覆盖前面的行为，命令行不报错。你以为加了两道保险，实际上只有一道。命令行的沉默有时候比报错更坑。

–where 和分批导出，省事也埋雷

表大的时候谁都不想一次性导几十个 G，于是加 –where=”id > 1000000 AND id < 2000000″ 分批来。这招确实管用，但有两个前提：一是你的主键得单调递增，二是导出期间不能有人在中间插入或者删数据，否则批次之间就会有缝隙和重叠。真要做增量式导出，靠 where 划区间只是权宜之计，正经的还是得有类似 binlog 位置或者时间戳字段这种依据。另外 –where 那串字符串里的引号处理很烦，你在 shell 里套一层单引号、SQL 里再套一层，不同 shell 的展开规则不一样，我见过因为这个把条件吃掉一半、导出来的数据少了一大截的。

还有 –ignore-table，很多人顺手用来跳过日志表。注意它的大小写和库名表名必须严格对应，写成 dbname.log 和 dbname.Logs 是两回事。Linux 上大小写敏感，跳过失败的后果就是你那几十 G 的日志表照样被卷了进去，磁盘写满，导出中断，前面几个小时白跑。这种坑说起来低级，真踩上去的时候人是懵的。

导出成功不等于能用，验证别省

命令跑完没报错，不代表文件能恢复。最起码的验证是拿 head 看一眼文件开头有没有建表语句、末尾有没有那行 dump 完成的标记，文件大小是不是和库的体量在一个量级。再狠一点，找一台测试机器真灌一遍，这步最花时间但也最值。我见过导出中途因为磁盘空间不够被 kill 掉，文件躺在那儿看着挺完整，最后一截是断的，灌的时候才报错，那会儿业务已经在等你上线了。

恢复阶段的反向坑：顺序和外键

导出时留的心眼，恢复的时候还得再来一遍。加了 –single-transaction 导出的文件，默认是带 SET 语句的，你在别的环境灌，会话变量被它改掉，某些情况下反而惹麻烦。另外外键约束在导入期间是个累赘，常见做法是导入时临时 SET FOREIGN_KEY_CHECKS=0，完事再打开。但这属于能省事也能出事的操作，导完一定要把开关恢复回去，别留在那，下次别人接手看到这个状态会骂人。

锁的问题也对称。导出时你没加锁，业务一直在写，那这份数据只能代表某个时间点，恢复回去等于把这段时间的写入丢了。导出之前想清楚：这次是要做冷备、要迁移、还是要拿下来做分析？三种目的对应的参数组合不一样，拿同一套命令套所有场景，早晚翻一次。

回到开头那三个参数——字符集、事务与锁的组合、导出范围。它们凑在一起，几乎覆盖了日常八成的导出事故。真要记不住那么多细节，就记一条：导完之后别急着宣布完成，先验证，再恢复一遍。命令是死的，事故都是活的。具体到你们用的版本和引擎，参数行为可能还有差别，以官方文档和实际测试结果为准。