核心业务零中断场景下MySQL大表迁移不停机方案对比

干咱们这行的，只要碰过线上那些千万行级的MySQL大表，都清楚直接跑离线导库是什么后果——锁表时间一长，业务那边能直接冲过来拍桌子。要想在完全不打断线上流量前提下把数据搬走，路子其实不多，影子表加增量同步差不多是必选项。但这套玩法特别吃服务器资源，要是事前没给CPU和IO留出三成以上的冗余，哪怕你已经挑了业务低峰期去跑，监控告警照样能给你刷得满屏通红。还有个坑，迁移工具选得不对，后半夜大概率就得爬起来回滚救火，那种滋味谁尝谁知道。

主流同步工具的脾气与适用边界

pt-osc跟gh-ost算是MySQL大表迁移圈子里出镜率最高的两个工具，但这俩底层逻辑差得挺远。pt-osc靠触发器捕捉写入变更，兼容性确实还行，可一旦碰上更新特别频繁的大表，主库CPU能直接往上蹿个10%到30%，对线上业务干扰不小。gh-ost脾气就不一样了，它假装成一台从库去拉binlog，把增量数据解析完再写进影子表，压根不用触发器那套东西，而且它可以随时暂停，也能动态限速，迁移过程的把控感强不少。我记得有个电商客户赶在大促前迁核心流水表，就是用gh-ost把并发压到2，慢慢磨了八个小时，线上用户连个卡顿都没感觉到。

物理备份与分片策略的取舍

要是你遇到整个实例都得搬走，或者单表数据量已经滚到了TB级别，直接用Xtrabackup配合主从切换这套方案反而更痛快。流程就是备份、追平主从延迟、再切应用连接，实际停服窗口能压到秒级别，不过有个前提，binlog必须开ROW格式，而且保留时长要足够兜住整个迁移周期，要是一不留神增量数据追不上，就真得全盘回滚从头再来。要是架构本身已经做了分库分表，那就只能按时间或者取模规则一块块去迁，再搭上双写机制、灰度切流慢慢校数据。这套迁移颗粒度最细，但代价也大，中间件路由甚至应用代码都得动，稍微不注意，分片延迟、数据冲突的问题就冒出来了。给大家个直白的选择标准：如果是持续高写入的单表，又能接受几小时的迁移周期，选gh-ost更稳妥；要是整库搬迁而且服务器环境条件到位，用物理备份切从库的方案能省不少心。

动工之前有几件事真的不能偷懒：表上必须有主键或者唯一索引，不然pt-osc和gh-ost根本跑不起来；磁盘怎么说也得留出1.5倍的空余空间，别等影子表把磁盘撑爆了才傻眼；记得提前把数据库超时参数调大，要不大事务回滚搞不好会直接把主从同步链路扯断。校验数据准不准，光数行数太粗糙了，最好用pt-table-checksum跑分段校验，或者算CRC32哈希值来比对才靠谱。碰上外键碍事就临时关掉foreign_key_checks，发现binlog过期赶紧调保留策略，同步速度掉下去了就果断降并发甚至暂停任务。提前把监控告警、回滚脚本、自动化校验流程全都配到位，这套MySQL大表不停机迁移的方案才真算能踏实落地不出错。