高并发下应合理利用数据库并发控制机制，优先选READ COMMITTED隔离级别、晚窄快加锁、固定表更新顺序、用乐观锁补充悲观锁，并避免事务边界模糊等问题。
高并发场景下，SQL事务冲突、死锁、数据不一致等问题频发，核心在于合理利用数据库的并发控制机制，而非单纯依赖应用层加锁或重试。
理解隔离级别与实际影响
不同隔离级别直接决定读写冲突概率和性能开销。MySQL默认的REPEATABLE READ能避免不可重复读，但幻读仍可能发生；而READ COMMITTED在多数OLTP场景中更平衡——它允许已提交的新数据被读到，降低间隙锁范围，减少死锁。
- 高频更新+强一致性要求（如账户余额）：可接受短时锁等待，用SELECT ... FOR UPDATE配合REPEATABLE READ
- 报表类查询或宽松一致性场景：改用READ COMMITTED，并关闭innodb_locks_unsafe_for_binlog（MySQL 5.6+已弃用，注意版本差异）
- 避免盲目设为SERIALIZABLE——它会将所有SELECT转为加锁读，吞吐量断崖式下降
优化锁粒度与持有时间
锁不是越早加越好，而是越晚加、越窄加、越快放越好。重点不在“防冲突”，而在“缩窗口”。
- 把非数据库操作（如HTTP调用、日志记录）移到事务外，确保BEGIN到COMMIT只做必要SQL
- UPDATE/DELETE尽量走主键或唯一索引，避免全表扫描触发表级锁或大量行锁
- 批量操作拆分为小批次（如每次100条），配合LIMIT和显式事务控制，防止长事务阻塞其他连接
主动规避死锁而非被动重试
死锁不是异常，是并发设计信号。重试只是兜底，关键在统一访问顺序和简化路径。
- 多个表更新时，始终按固定顺序（如字母序、ID升序）加锁，例如先更新orders再更新inventory，所有业务逻辑保持一致
- 避免在事务中执行子查询依赖外部状态（如SELECT后根据结果再UPDATE），这类逻辑易导致锁顺序不可控
- 用SHOW ENGINE INNODB STATUS定期分析死锁日志，重点关注WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)段落，定位冲突热点行
用乐观锁补充悲观控制
对冲突概率低、更新频率适中的场景（如文章点赞数、订单状态轻量变更），乐观锁比行锁更轻量。
- 在表中增加version字段或用updated_at时间戳，在UPDATE时校验：UPDATE t SET cnt = cnt + 1, version = version + 1 WHERE id = ? AND version = ?
- 应用层捕获影响行数为0的情况，决定是否重读重试——注意避免ABA问题，必要时引入CAS语义或业务版本号
- 不适用于高冲突场景（如秒杀库存扣减），此时仍应以悲观锁+队列削峰为主
不复杂但容易忽略。真正压测时暴露的问题，往往不是SQL写法，而是事务边界模糊、锁范围失控、隔离级别误用这三类设计惯性。
