搞数据库的人，谁没在表迁移上栽过跟头？我刚入行那会儿，接手一个ERP系统的升级，要把老Oracle里的订单表挪到新MySQL里。心想不就是建个表、导个数据吗？结果数据一跑，几十万条订单的金额对不上，客户那边差点炸锅。后来花了整整三天排查，才发现是字段类型转换时，Oracle的NUMBER(10,2)被MySQL默认截成了DECIMAL(10,0)，小数点后的钱全掉了。那三天我睡得比狗晚、起得比鸡早，每次电话响都吓得一激灵。从那以后，我学乖了——表迁移这事儿，看着简单，处处是坑。今天就跟大伙儿聊聊，怎么从零到一，把这张表搬得稳当、不出幺蛾子。
第一步，别急着动手，先摸底。很多新手上来就敲CREATE TABLE，结果迁移到一半发现字段类型不兼容、索引重复、字符集对不上，进退两难。我现在的习惯是，先在原库跑一遍全量元数据查询：查字段名、字段类型、是否允许NULL、默认值、字符集、排序规则、索引类型、外键约束、触发器、视图依赖——一个都不能漏。比如MySQL的TINYINT(1)和Oracle的NUMBER(1)看着像，实际语义完全不同，前者是布尔值，后者是数值。还有字符集，老系统可能用latin1，新库默认utf8mb4，长度一算错，中文直接变问号。这些细节，靠拍脑袋是猜不出来的。花半小时跑个脚本，把信息列成表格，后面每一步都有依据，心里踏实。
摸底完了，就到了最考验耐心的环节——建表结构。别图省事儿，直接拿原库的DDL脚本在新库跑一遍。但注意，不是原样照搬。你得手动调整几样东西：字段类型要按目标库的规范改写，比如MySQL的DATETIME能存到‘1000-01-01’，而Oracle的DATE最小是‘4712-01-01’，如果原表有‘00-00-00’这种奇葩值，不处理直接导入，新库会报错自杀。索引也得重新评估，原库可能因为历史冗余建了十几个索引，但新库的业务场景不同，有些索引根本用不上，留着反而拖慢写入速度。主键、外键、唯一约束，这些牵一发动全身的东西，更是得逐条确认。我一般会在测试库先跑一遍完整的建表脚本，然后对比原库的表结构，逐字段、逐索引地过，确保一模一样，连默认值的小数点位数都不差。
结构建好了，别急着倒数据。先做一波“空跑”——往新表里插入一条正常数据、一条边界数据、一条异常数据。为什么要这么干？因为很多坑只有在数据真正落地时才暴露。比如MySQL的VARCHAR(255)在Oracle里对应的是VARCHAR2(255)，但Oracle的VARCHAR2是按字节算的，一个汉字占三个字节，255字节只能存85个汉字。如果不测，业务数据里有长中文描述，直接截断，客户投诉马上来。还有自增ID，原库可能用SEQUENCE，新库用AUTOINCREMENT，你得先设好初始值，否则迁移后插入新数据，ID冲突就麻烦了。空跑这一步，看着繁琐，实则是整个迁移的“保险丝”。我自己就吃过亏——之前有个项目跳过了空跑，结果迁移后有个字段的默认值是CURRENTTIMESTAMP，但两个数据库的时区设置不一样，时间差了8小时，查了三天才定位到。
空跑通过，可以上全量数据导入了。但别傻乎乎地一条条INSERT INTO。数据量一大，这种写法能把新库拖死。我常用的策略是分批次导出、分批导入。比如用mysqldump导出时加--where条件，按时间窗口或ID范围切成若干个小文件，每个文件控制在100MB以内。导入时也别一股脑并行跑，数据库的连接池和事务日志扛不住。我一般用管道或脚本控制并发数，比如同时跑4个线程，每个线程处理一个文件。过程中持续监控新库的CPU、内存、磁盘IO，如果发现压力过大，立马停掉两个线程。还有一个容易被忽略的点——大事务。如果一次INSERT涉及十几万行，MySQL的binlog会膨胀到几个G，不仅慢，还容易引发死锁。所以一定要把大事务拆成小批次，每批1000到5000行，配合BEGIN...COMMIT，既能保证一致性，又不拖垮性能。
数据导完，你以为万事大吉？Too young。最关键的校验环节来了。我习惯做三件事：行数校验、关键字段校验、业务逻辑校验。行数校验最简单，SELECT COUNT(*)两边跑一遍，数字对不上就说明有漏的。但光看总数不够，还得按条件分组校验，比如按日期、按状态、按客户ID。为啥？因为如果只是总数一致，但某一天的数据全丢了，总数可能被别的数据补回来，你根本发现不了。关键字段校验更细致，我一般会抽几个核心字段，比如金额、时间、状态，用MD5把两边的值算一遍，比对摘要值是否一致。一旦发现不一致，立刻定位到具体记录。业务逻辑校验是一道防线——找业务方配合，跑几个典型的查询场景，比如“查最近30天未发货的订单”，看看结果跟原库是否一致。这一步虽然耗时，但能堵住绝大多数漏网之鱼。
校验通过，还不能松气。数据库表迁移的终局不是数据搬完，而是业务无感切换。这涉及到切换方案的制定：是停机迁移还是在线迁移？停机迁移最简单，业务暂停几小时，你把数据全量导过去，验证完就切DNS或改连接串。但很多互联网业务不能停，那就得用在线迁移方案。比如用CDC工具（像Debezium或Canal）实时同步增量数据，同时全量迁移历史数据。但注意，CDC的延迟和断流问题得提前测好。我见过一个项目，CDC在凌晨3点断流了，运维没发现，第二天业务跑了8小时才发现数据对不上，不得不回滚。所以无论选哪种方案，都要准备回滚脚本：把新库的数据清空，把原库恢复成迁移前的状态。回滚脚本要提前写好、提前测，别等出事了再现写。
最后我想说一句大实话：数据库表迁移，本质上是一场“预防医学”。你前期准备得越细，后面踩的坑就越少。别指望靠运气蒙混过关，也别迷信某个工具能解决所有问题。我见过太多人，要么被压测数据吓到，要么被线上问题逼疯，只能硬着头皮上。但如果你愿意多花20%的时间做摸底、空跑、校验，后面的80%时间就能从容应对。记住，迁移从来不是技术活，而是体力活加细心活。每一张表背后，都是真实业务和真实用户。所以，慢一点、细一点、多问一句“这个字段会不会出问题”，比什么都强。下次你接手表迁移任务时，不妨先泡杯茶，把这篇避坑指南从头到尾再过一遍。你会发现，从零到一，真的没那么可怕。
