MySQL迁移需减少锁竞争，合理使用在线DDL工具如pt-osc或gh-ost，控制事务大小，避开高峰，实时监控锁状态，避免阻塞与数据不一致。
MySQL迁移过程中，锁机制的处理直接影响数据一致性与服务可用性。尤其在主从切换、跨机房迁移或版本升级时，若未妥善应对锁问题，容易引发阻塞、死锁甚至数据丢失。核心思路是减少锁竞争、控制事务粒度、合理安排迁移步骤。
理解迁移中的常见锁类型
迁移期间主要涉及表锁、行锁和元数据锁（MDL）：
- 表锁：如ALTER TABLE操作可能触发全表锁定，长时间阻塞读写。
- 行锁：InnoDB在事务中修改数据时加行锁，大事务易导致锁等待。
- MDL锁：执行DDL语句时自动获取，会阻塞后续DML操作，尤其在高并发场景下影响明显。
识别这些锁的来源有助于提前规避风险。
使用在线DDL工具减少锁影响
直接执行DDL语句容易造成服务中断。推荐使用pt-online-schema-change或gh-ost等工具进行无锁变更：
- pt-online-schema-change：创建影子表，通过触发器同步增量数据，最后原子替换原表，最大限度减少锁持有时间。
- gh-ost：GitHub开发的工具，无需触发器，基于binlog同步，更安全且对源库压力小。
两者都能避免长时间持有表锁，适合大表结构迁移。
控制事务大小与执行窗口
迁移过程中应避免大事务操作：
- 拆分大批量INSERT/UPDATE/DELETE为小批次，每批提交后短暂休眠，释放行锁。
- 选择业务低峰期执行迁移任务，降低锁冲突概率。
- 设置合理的lock_wait_timeout和innodb_lock_wait_timeout，防止长时间等待拖垮连接池。
监控锁状态并及时干预
迁移期间实时查看锁信息至关重要：
- 通过SHOW ENGINE INNODB STATUS查看最近的死锁信息。
- 查询information_schema.INNODB_TRX定位长事务。
- 使用performance_schema.data_locks分析当前持有的锁。
发现阻塞链后，可考虑杀掉非关键事务，快速恢复服务。
基本上就这些。关键是提前规划、用对工具、小步推进，避免一次性大动作引发连锁反应。
