在MySQL迁移过程中，锁冲突是常见问题，尤其在主从切换、数据同步或在线DDL操作时容易发生。处理不当会导致业务阻塞、延迟甚至中断。核心思路是减少锁的持有时间、避免长事务，并合理安排迁移步骤。

1. 减少锁竞争：避免长事务和大事务

长时间运行的事务会持续持有行锁或表锁，增加与其他操作冲突的概率。

• 拆分大事务为多个小事务，例如每处理1000条记录提交一次
• 迁移前检查并终止长时间运行的事务：
  SHOW PROCESSLIST;
  发现状态为 Locked 或运行时间过长的连接，可考虑 kill 对应线程（谨慎操作）
• 关闭自动提交模式时，确保及时手动提交（COMMIT），避免忘记导致锁长期未释放

2. 使用低影响的DDL策略

ALTER TABLE 等操作在旧版本MySQL中容易引起表级锁，阻塞读写。

一款集成AI换脸、照片跳舞等多种AI特效玩法的App

• 使用 pt-online-schema-change（Percona Toolkit）或 gh-ost 工具进行在线DDL变更，避免锁表
• 确认 MySQL 版本支持 InnoDB DDL 的并发特性（如 5.6+ 支持某些操作的 online DDL）
• 尽量将结构变更放在迁移窗口期执行，避开业务高峰

3. 主从复制中的锁问题处理

在基于主从架构的迁移中，从库应用中继日志时可能因查询执行时间长引发锁等待。

• 确保从库的 SQL 线程不落后太多，避免积压任务集中加锁
• 监控复制延迟：
  SHOW SL*E STATUS\G
  关注 Seconds_Behind_Master 和 Running_Sl*e_SQL 状态
• 避免在从库执行长时间 SELECT ... FOR UPDATE 或显式加锁查询

4. 应用层配合：控制并发与重试机制

迁移期间数据库负载升高，应用需具备容错能力。

• 临时降低非关键业务的并发请求量
• 对因死锁或超时失败的操作实现指数退避重试逻辑
• 设置合理的锁等待超时时间：
  innodb_lock_wait_timeout 建议设为 30~60 秒，防止长时间阻塞