在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. 应用层配合：控制并发与重试机制
迁移期间数据库负载升高，应用需具备容错能力。
临时降低非关键业务的并发请求量 对因死锁或超时失败的操作实现指数退避重试逻辑 设置合理的锁等待超时时间：innodb_lock_wait_timeout 建议设为 30~60 秒，防止长时间阻塞 基本上就这些。关键是提前评估锁风险，选择合适工具和时机，把影响降到最低。
