数据库表数据迁移这事儿，干过的都知道，看着简单，真上手时能让人头皮发麻。我有个朋友，前阵子公司系统升级，要把几十张表从 MySQL 搬到 PostgreSQL，他以为就是导出导入，结果呢？数据量大了之后，导出文件卡死，导入时字段类型不兼容、字符集乱码，折腾了三天三夜，还丢了一部分订单数据。老板差点让他卷铺盖走人。这事不算稀奇，很多开发新手甚至老手，都栽在“想当然”上。数据迁移不是复制粘贴，它像拆弹，每一步都得小心翼翼。
先说准备阶段。很多人一上来就写脚本跑，结果跑到一半发现表结构对不上，或者主键冲突。我建议，动手之前先画张表：源库的表结构、字段类型、索引、约束、外键关系，全列出来。然后对照目标库，把差异标红。比如 MySQL 的 datetime 和 PostgreSQL 的 timestamp，看着像，但精度和时区处理不一样，不提前改好，导入后数据就歪了。还有自增主键，MySQL 用 AUTOINCREMENT，PostgreSQL 用 SERIAL，迁移时得手动重置序列，否则插入新数据会报错。这些细节，写个文档记下来，比拍脑袋强十倍。
数据量是关键变量。几百行数据的迁移，写个 SQL 语句就搞定。但到了几十万行，甚至上千万行，事情就变味了。我见过一个案例，某电商平台迁移用户表，三百万条记录，直接用 SELECT * INTO 导出，结果数据库锁了半小时，线上订单全卡住。后来他们改成分批迁移，每次只取一万条，用 OFFSET 和 LIMIT 控制，配合业务低峰期操作，才搞定。分批迁移时，还要注意数据的一致性。迁移过程中源库仍在写入新数据，就得用事务或快照锁定，否则两边数据对不上，对账会逼疯运维。
数据校验是大多数人忽略的坑。迁移完了，以为万事大吉，结果上线后发现某字段全是 NULL，或者金额精度少了两位。我有个同行，迁移财务系统的流水表，导入后没做校验，第二天财务对账差了五十多万，查了一天，发现是浮点数精度问题——MySQL 的 float 被转成了 decimal，四舍五入规则不一样。从那以后，他每次迁移完，都写脚本对比源库和目标库的记录数、关键字段的哈希值，甚至抽样几万条逐行比对。这活累，但能保命。
性能问题也得提前想好。迁移过程中，源库和目标库的资源占用会飙升。比如导出时，大量读取会压垮磁盘 I/O，导入时索引重建和约束检查又会吃 CPU。我见过一个团队，迁移时没限流，结果目标库的磁盘直接写满，迁移进程崩溃，还得回滚。靠谱的做法是：迁移前评估源库的磁盘空间和 IOPS，目标库的内存和 CPU，必要时加限速参数。比如 MySQL 的 mysqldump 用 --single-transaction 和 --quick，PostgreSQL 的 pgdump 用 -j 并行参数，但别开太多，否则网络带宽会成瓶颈。
工具选择也有门道。有人喜欢用 ETL 工具，如 DataX、Kettle，这些能可视化配置，但上手成本高，遇到复杂转换还得写脚本。有人偏爱命令行，如 mysqldump、pgdump，简单直接，但遇到不兼容的字段类型，得手动改 SQL。还有个折中的办法：用 Python 写脚本，结合 pandas 把数据读成 DataFrame 再写进去，灵活性高，但性能一般，处理千万级数据会慢。我个人的习惯是：小规模用命令行，大规模用定制脚本，配合日志模块记录每一步的耗时和错误，方便排查。
别忘了回滚方案。迁移失败是常态，成功才是意外。我认识一个 DBA，迁移前会先做全量备份，然后建个沙箱环境，在沙箱里跑一遍迁移流程，验证通过后才动生产。他还习惯在目标库上保留一个“回滚点”，比如把旧表重命名为 bak， 新表上线后运行一周，确认无误再删掉备份。这招看着笨，但真能救命。有一次他迁移用户权限表，上线后发现新表漏了一个字段，导致用户登录后看不到菜单，他二话不说把旧表换回来，五分钟就恢复了。
说说心态。数据迁移不是一锤子买卖，它是个持续优化的过程。你可能会遇到各种意想不到的问题，比如网络抖动导致传输中断、源库版本升级后兼容性变化、甚至业务方临时改需求要加字段。我有个同事，做数据迁移做了五年，他说自己最大的进步不是技术，而是学会了“认怂”。遇到搞不定的问题，别硬扛，先停下来，查文档、问社区、找专家，哪怕多花一天，也比上线后出事故强。说到底，数据是公司的命根子，你拿它练手，就得有敬畏心。
所以，下次有人让你做数据迁移，别急着拍胸脯。先问清楚数据量、表结构、业务场景，再评估工具和风险，做好准备。这活不轻松，但干好了，你就是团队里最靠谱的那个人。毕竟，能把数据安安稳稳地从 A 搬到 B，还能让业务无感，这本身就是一种本事。
