干这行这么多年，最怕听到的一句话就是：“帮我把这个表挪到另一个库去。”听起来轻飘飘的，干起来全是坑。表结构不一样、字段类型对不上、数据量一大就超时、主键冲突、外键约束……随便哪个冒出来都能让你加班到深夜。但你要是真把这事琢磨透了，会发现跨库复制这事儿，本质上就三步：搞清楚要搬什么，选对搬的方法，搬完仔细验一遍。今天就把这三步掰开揉碎了讲清楚。
第一步，也是最容易被忽略的一步——盘点清楚你手里的表到底是个什么脾气。很多人上来就SELECT FROM 老表，然后INSERT INTO 新表，结果跑到一半报错，才发现新表字段少了一个，或者类型对不上。所以动手之前，先花十分钟把表结构拉出来看看：有哪些字段、什么类型、有没有默认值、主键外键、自增列、索引、触发器、存储过程……这些都得心里有数。特别是外键，你要是只搬了主表没搬子表，新库里一插数据直接报违反约束。还有自增列，源表ID已经走到100了，你搬到新表从1开始，后面业务对接全是乱套的。所以第一步不是写代码，是画地图——把这个表关联的东西全摸清楚。
第二步，选搬法。市面上常见的有三种，各有利弊。第一种是数据库自带的导出导入工具，比如MySQL的mysqldump、PostgreSQL的pgdump，或者SQL Server的生成脚本。这种办法适合小表，几万行以内，结构简单，一条命令搞定。但表一大了就露怯，几十G的表导出再导入，中间断个网你就哭吧。第二种是SQL直连，就是两个库之间建立链接，直接INSERT INTO ... SELECT FROM ...。这种办法灵活，可以加WHERE条件只搬一部分数据，也能在搬的过程中做字段映射。但跨库直连对网络要求高，数据量一大容易把网络带宽占满，影响线上业务。第三种是用专业的数据同步工具，比如DataX、Kettle、Debezium这些。这些工具支持断点续传、增量同步、数据校验，适合大数据量或者需要定期同步的场景。但学习成本高，配置麻烦，小项目用起来有点杀鸡用牛刀。我的建议是：数据量小、一次性迁移，用工具导出导入；数据量中等、能接受停机窗口，用SQL直连；数据量大、要求不停机，别自己折腾了，直接上专业工具。
第三步，也是很多人栽跟头的地方——验证。搬完了不代表完事了，你得确认搬过来的数据跟源库一致。最简单的方法是比对行数，SELECT COUNT() FROM 两张表，数字对上了，心里先踏实一半。但行数一致不代表数据一致，比如某个字段的值被截断了，或者日期格式变了，行数还是对的。所以还得抽几个关键字段比对一下，最狠的办法是拿MD5或者哈希值比对整行数据，但数据量大了太耗时。折中方案是随机抽样几百条，比对每个字段的值。另外别忘了检查自增列的下一个值，还有那些触发器、存储过程是不是也跟着搬过来了。我自己吃过一次亏，搬完表忘了搬触发器，结果业务上线后该自动更新的字段全没更新，第二天早上被业务方电话轰炸。
说完这三步，再聊几个实操中容易踩的坑。第一个是字符集问题。源库是UTF8，目标库是GBK，搬过去中文全变问号。所以建新表之前，先确认字符集和排序规则跟源库一致。第二个是时间类型。源库用的是DATETIME，目标库用了TIMESTAMP，范围不一样，超过2038年的日期直接报错。第三个是NULL值。源库某字段允许NULL，目标库建表时忘了加NULL约束，插入时就报错。这些细节看着小，但每一个都能让你白忙活一晚上。所以更稳妥的做法是，先建好表结构，再导数据，别让工具自动建表——自动建表常常把约束、索引、注释全丢了。
再补一个很多人不知道的小技巧。如果你用的是MySQL，搬表之前先关掉外键检查，SET FOREIGNKEY_CHECKS=0，搬完再打开。这样就不用担心子表没搬完主表先搬了导致报错。但切记，搬完一定要重新打开，不然以后删数据删不干净。PostgreSQL的话，可以先用ALTER TABLE DISABLE TRIGGER ALL禁用触发器，搬完再ENABLE。这些小操作能省你不少心。
说了这么多，其实跨库复制这事本身不复杂，复杂的是各种边界情况。你永远不知道线上那堆表背后藏着多少历史包袱——某个字段名拼错了但没人敢改，某个类型当年图省事全存了字符串，某个外键连了三层但文档一个字没写。所以我的建议是，把这三步当成一个固定的流程，每次迁移都走一遍：盘点、搬移、验证。哪怕你觉得这次的表很简单，也别跳过验证那一步。程序员的自信，往往就是线上事故的开端。
说句掏心窝子的，数据库迁移这事，慢就是快。宁可多花半小时做准备，也别图省事直接一把梭。毕竟生产环境的数据库，出一次事，你前半年攒的绩效可能就搭进去了。这三步看起来平平无奇，但每一步背后都是前人踩过的坑。你照着走一遍，至少能保证不捅大篓子。至于那些更刁钻的场景，比如跨云厂商迁移、跨版本升级、不停机同步，那就不是一篇文章能讲完的了，得单独开个系列慢慢聊。
