高并发下应合理利用数据库并发控制机制，优先选 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 写法，而是事务边界模糊、锁范围失控、隔离级别误用这三类设计惯性。
