减少锁冲突需优化事务设计与索引使用。1. 缩短事务时间，将非数据库操作移出事务并及时提交。2. 为WHERE条件字段创建索引，避免全表扫描和隐式类型转换。3. 减少锁范围，分批处理批量更新，优先用主键或唯一索引更新。4. 选用合适隔离级别，如READ COMMITTED以减少间隙锁。5. 避免死锁，按固定顺序访问表并设置重试机制。结合这些策略可显著降低锁冲突。
减少 MySQL 锁冲突的核心在于优化事务设计、合理使用索引、缩短锁持有时间以及选择合适的隔离级别。以下是一些实用策略。
1. 缩短事务执行时间
事务越长，持有的锁时间也越长，发生锁冲突的概率就越高。
- 尽量将非数据库操作（如网络请求、文件处理）移到事务外部。
- 避免在事务中加入用户等待或长时间计算逻辑。
- 及时提交或回滚事务，不要长时间保持开启状态。
2. 合理使用索引避免表锁或间隙锁
没有索引时，MySQL 可能会进行全表扫描，导致大量行被加锁，甚至升级为表锁。
3. 减少锁的范围和数量
尽量只锁定必要的数据行，避免不必要的锁竞争。
- 批量更新时分批操作，每次处理少量数据，释放后再继续。
- 避免一次性更新大量数据，可拆分为多个小事务。
- 使用主键或唯一索引更新，避免使用非唯一条件引发间隙锁（Gap Lock）。
4. 选择合适的隔离级别
高隔离级别（如可重复读）容易产生更多锁，特别是间隙锁。
- 如果应用允许，可将隔离级别设为 READ COMMITTED，减少间隙锁使用。
- 在该级别下，InnoDB 的 next-key lock 退化为行锁，显著降低死锁概率。
- 注意：READ COMMITTED 下可能读到“不可重复读”数据，需业务容忍。
5. 避免死锁和重试机制
虽然不是直接减少锁冲突，但能提升系统整体并发稳定性。
- 多个事务访问多张表时，约定一致的加锁顺序，防止循环等待。
- 捕获死锁错误（如 1213 错误），自动重试事务。
- 使用 innodb_deadlock_detect 和 innodb_lock_wait_timeout 调整检测与超时行为。
基本上就这些。关键是在业务设计阶段考虑并发场景，结合索引优化和事务控制，就能大幅降低锁冲突带来的性能问题。