答案：MySQL迁移中锁冲突需通过减少锁持有时间、避免长事务和合理安排步骤来控制。1. 拆分大事务并及时提交，终止长时间运行的连接；2. 使用pt-online-schema-change或gh-ost工具进行在线DDL，避开业务高峰执行结构变更；3. 监控主从复制延迟，避免从库积压导致锁等待；4. 应用层降低并发、设置重试机制与合理超时。核心是评估风险、选对工具与时机以降低影响。
在MySQL迁移过程中，锁冲突是常见问题，尤其在主从切换、数据同步或在线DDL操作时容易发生。处理不当会导致业务阻塞、延迟甚至中断。核心思路是减少锁的持有时间、避免长事务，并合理安排迁移步骤。
1. 减少锁竞争：避免长事务和大事务
长时间运行的事务会持续持有行锁或表锁，增加与其他操作冲突的概率。
- 拆分大事务为多个小事务，例如每处理1000条记录提交一次
- 迁移前检查并终止长时间运行的事务：
SHOW PROCESSLIST;
发现状态为 Locked 或运行时间过长的连接，可考虑 kill 对应线程（谨慎操作） - 关闭自动提交模式时，确保及时手动提交（COMMIT），避免忘记导致锁长期未释放
2. 使用低影响的DDL策略
ALTER TABLE 等操作在旧版本MySQL中容易引起表级锁，阻塞读写。
- 使用 pt-online-schema-change（Percona Toolkit）或 gh-ost 工具进行在线DDL变更，避免锁表
- 确认 MySQL 版本支持 InnoDB DDL 的并发特性（如 5.6+ 支持某些操作的 online DDL）
- 尽量将结构变更放在迁移窗口期执行，避开业务高峰
3. 主从复制中的锁问题处理
在基于主从架构的迁移中，从库应用中继日志时可能因查询执行时间长引发锁等待。
- 确保从库的 SQL 线程不落后太多，避免积压任务集中加锁
- 监控复制延迟：
SHOW SLAVE STATUS\G
关注 Seconds_Behind_Master 和 Running_Slave_SQL 状态 - 避免在从库执行长时间 SELECT ... FOR UPDATE 或显式加锁查询
4. 应用层配合：控制并发与重试机制
迁移期间数据库负载升高，应用需具备容错能力。
基本上就这些。关键是提前评估锁风险，选择合适工具和时机，把影响降到最低。
