干了十来年数据活儿，最怕听见的一句话就是“把那边数据弄过来一下”。轻飘飘一句话，背后是字符集、字段类型、主键冲突、时间格式、NULL值、大字段、增量同步……哪一样都能让人加班到天亮。跨库迁移这事儿，看着是搬运工干的体力活，实际上全是技术活加运气活。今天不聊那些官方文档里抄来的理论，就说说实战里踩过的坑，和那些真正能让你早俩小时下班的土办法。
先说说最常见的坑：字符集。你从MySQL往Oracle导数据，源库是utf8mb4，目标库是ZHS16GBK，中文看着没问题，一遇到emoji或者生僻字，直接报错或者变成问号。我见过最离谱的一次，某个用户昵称里带了个生僻人名用字，整张表同步中断，排查了一下午。解决办法其实不复杂，迁移前先查两边的字符集和排序规则，统一用UTF-8做中间格式，导出文件明确指定编码，导入前再验证一遍。别嫌麻烦，这一步能省掉后面80%的乱码问题。
再说字段类型映射。MySQL的tinyint(1)到了PostgreSQL里可能就变成boolean，看起来差不多，实际查询逻辑全变了。还有DECIMAL精度，源库是DECIMAL(10,2)，目标库写成了DECIMAL(8,2)，数据量小看不出来，一旦金额超过六位数，直接溢出报错。我的习惯是先把源库的表结构全部导出，手工过一遍字段清单，对照目标库的类型映射表一个个核对。特别是日期时间类型，MySQL的datetime和timestamp在Oracle里可能对应DATE和TIMESTAMP，精度差一秒，报表对不上，老板就找你。
主键和唯一索引是另一个大坑。源库允许NULL值的主键，到了目标库主键不允许NULL，导入直接炸。还有那种复合主键顺序不一致的，明明数据一样，查出来结果却对不上。更头疼的是自增ID，MySQL的AUTO_INCREMENT和SQL Server的IDENTITY，迁移后如果不重置序列，新插入的数据就会主键冲突。实战中我一般先禁用目标库的约束和触发器，导入完成后再重新启用，这样能避免很多因为约束导致的误报错。
大字段和BLOB/CLOB是性能杀手。一张表里有个TEXT字段存JSON，几百万行数据，用普通的INSERT语句逐条插入，跑一晚上都完不成。后来我改用批量提交，每500条一个事务，速度提升明显。但批量也有坑，某次迁移遇到一条数据里有个超大的二进制字段，导致整个批量事务回滚，前面的全白干了。所以大字段要单独处理，先导结构再导数据，大字段单独用流式读取写入，别跟普通字段混在一起。
增量同步比全量更考验功力。全量迁移顶多慢点，增量同步搞不好就丢数据。用时间戳做增量标记的，源库记录被物理删除就漏了；用日志解析的，比如基于binlog或redo log的，配置复杂且版本兼容性问题多。我常用的土办法是，全量导入后用主键或唯一键做比对，把差异数据单独同步。如果源库有LastModified时间字段，就用它做增量游标，但记得要处理跨天和时区问题。还有一种情况是源库有应用层的软删除逻辑，这个靠时间戳抓不到，必须结合业务规则来补。
效率提升这块，并行比什么都重要。单线程导几千万行数据，那是给自己找罪受。用并行导出工具按分区或主键范围拆分任务，每个线程处理一个分片，速度能提升好几倍。但并行也有副作用，目标库的锁竞争和磁盘IO会飙升，搞不好把生产库拖垮。所以并行度要控制，先小规模测试，观察目标库的负载情况再逐步加大。另外，如果源库和目标库之间网络带宽有限，压缩传输是个好办法，我曾经把15GB的导出文件压缩到3GB，传输时间缩短了70%。
说一个很多人忽略的点：数据校验。迁移完不等于完事，必须做双向校验。我通常是抽样加全量两种方式结合，先随机抽几千条比对关键字段，再对主键唯一键做全量比对，确认没有重复和缺失。有个更省事的办法是统计每张表的行数和关键列的SUM值，两边对不上再去查明细。但光对数字还不够，我吃过一次亏，行数对上了，某列的数据整体偏移了一位，这种只能靠字段级别的哈希比对才能发现。
跨库迁移这事儿，说难也难，说简单也简单，关键是把每一步都当成可能出问题的地方来对待。工具选得再好，不如自己心里有数。字符集、类型映射、主键约束、大字段处理、增量策略、并行度控制、数据校验，这七关每一关都过一遍，基本就能睡个安稳觉了。下次再有人跟你说“把数据弄过来一下”，你先别急着动手，把这几件事问清楚，能省下无数个不眠之夜。
