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分析当前持有的锁。发现阻塞链后，可考虑杀掉非关键事务，快速恢复服务。
基本上就这些。关键是提前规划、用对工具、小步推进，避免一次性大动作引发连锁反应。
