陷阱一：忽略隐式锁导致业务长时间阻塞
使用mysqldump导出时，默认会获取全局读锁（FLUSH TABLES WITH READ LOCK），若表上有未提交的长事务，锁等待可能持续数分钟。规避方法：使用--single-transaction开启InnoDB一致性快照，但需确保所有表均为InnoDB且无DDL并发。
真实案例：某电商平台在促销期间执行迁移，未检查information_schema.innodb_trx，导致锁等待120秒，核心订单接口全部超时。教训：迁移前必须执行SELECT * FROM information_schema.innodb_trx\G确认无活跃长事务。
陷阱二：主从延迟被低估，切换后数据不一致
主从复制延迟不仅取决于网络，还受目标库硬件性能影响。若目标库磁盘IOPS不足，延迟可能持续扩大。建议：
- 迁移前在目标库执行
sysbench压测，确保IOPS高于源库。 - 监控
SHOW SLAVE STATUS中的Seconds_Behind_Master，当该值持续增长时立即暂停迁移。 - 使用
pt-heartbeat精确测量延迟（精度0.01秒），避免秒级误判。
陷阱三：字符集与排序规则不匹配
源库为utf8mb4_general_ci，目标库误设为utf8mb4_unicode_ci，会导致索引失效和排序结果差异。迁移前必须对比：
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='db_name';并在目标库显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，同时检查所有VARCHAR列定义。
陷阱四：外键约束导致导入失败
当表之间存在外键关系时，若导入顺序颠倒（先导入子表后导入父表），会触发外键检查错误。解决方案：在导入前执行SET FOREIGN_KEY_CHECKS=0，导入完成后重新启用，并手动执行CHECK TABLE验证完整性。
陷阱五：自增主键冲突与空洞
使用mydumper导出时，默认会保留自增值，但若目标表已有数据，可能冲突。建议导出时使用--no-data先建表，再使用--trx-consistency-only导出数据，导入后执行ALTER TABLE tbl AUTO_INCREMENT=1重新计算。
陷阱六：大字段（TEXT/BLOB）导致内存溢出
默认max_allowed_packet为4MB，若表中有超过该值的大字段，导入会报错。迁移前执行SET GLOBAL max_allowed_packet=1G，并同步调整客户端参数。
陷阱七：迁移后索引统计信息未更新
导入大量数据后，优化器仍使用旧统计信息，导致执行计划偏差。必须执行ANALYZE TABLE tbl更新统计信息，并建议开启innodb_stats_auto_recalc=1。
陷阱八：忽略触发器与存储过程
mysqldump默认不导出触发器，若源表有触发器，迁移后业务功能缺失。使用mysqldump --triggers --routines --events导出，或单独导出后手动应用。
陷阱九：数据校验不全面
仅对比行数远远不够，必须做行级校验。推荐工具：
pt-table-checksum：基于主键分块计算CHECKSUM，对比主从差异。- 自定义SQL：
SELECT COUNT(*), SUM(CRC32(CONCAT_WS('#', col1, col2, ...))) FROM tbl，对比源库与目标库结果。
陷阱十：回滚预案缺失
很多团队迁移前未准备回滚脚本，一旦失败只能手工恢复。建议：
- 迁移前对源库做物理备份（XtraBackup），保存到独立存储。
- 记录迁移开始时的binlog位置，用于反向回放。
- 制定书面回滚步骤，并安排专人演练。
迁移后三日观察清单
迁移完成后，需持续监控：
- 慢查询日志中是否有新出现的全表扫描。
- 主从延迟是否归零且稳定。
- 磁盘空间增长是否异常（如undo log膨胀）。
- 应用错误日志中是否有死锁或超时。
遵循以上清单，可将大表迁移成功率提升至99%以上。