MySQL 高并发事务关键在于用得对、用得稳：控制短事务边界、选 READ COMMITTED 隔离级别、WHERE 走索引精准加锁、捕获死锁错误并幂等重试。
MySQL 在高并发场景下使用事务，核心不是“用不用事务”，而是“怎么用得对、用得稳”。关键在于减少锁冲突、控制事务粒度、避免长事务，并配合合理的隔离级别和索引设计。
控制事务边界：短小、明确、及时提交
高并发下最 常见问题 是长事务——它会持 有锁 时间过长，阻塞其他事务，甚至拖垮整个数据库。事务应只包裹真正需要原子性的一组操作，且越快结束越好。
- 避免在事务内做网络请求、文件读写、复杂计算等耗时操作
- 不要把用户交互（如等待 前端 确认）放在事务中
- 用 START TRANSACTION 显式开启，COMMIT或 ROLLBACK 必须成对出现，禁止依赖自动提交（autocommit=1）来“假装”事务
- 例如：扣减库存 + 记录订单，这两个操作必须在一个事务里；但生成支付链接、发短信通知这些，应该在事务外异步处理
合理选择隔离级别：读已提交（RC）通常是高并发首选
MySQL 默认是可重复读（RR），它通过间隙锁（Gap Lock）防止幻读，但在写多读多场景下容易引发锁竞争和死锁。大多数业务并不需要 RR 的强一致性，READ COMMITTED既能避免脏读，又大幅减少锁范围，提升并发能力。
- 确认业务能否接受“同一事务中两次 SELECT 可能看到不同数据”（即不可重复读）
- 如果用 RC，InnoDB 只对被修改的行加记录锁，不加间隙锁（除非显式加锁如SELECT … FOR UPDATE）
- 可在会话级设置：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
优化锁行为：少锁、快锁、精准锁
锁是并发 性能瓶颈 的直接来源。要让事务“锁得准、放得快”：
- WHERE 条件必须走索引，否则会升级为表锁或全表扫描 + 行锁，极大增加冲突概率
- 更新前尽量先用 SELECT … FOR UPDATE 加锁，但务必带有效索引条件，且避免 ORDER BY、LIMIT 等导致锁范围扩大
- 批量更新拆分为小批量（如每次 100 条），避免单个 UPDATE 语句锁住几千行
- 考虑乐观锁替代悲观锁：在更新语句中加入版本号或时间戳校验，失败则重试（适合冲突率低的场景）
规避死锁与重试机制不可少
即使设计再好，高并发下死锁仍无法完全避免。重点不是消灭死锁，而是快速识别、安全重试。
- 捕获 MySQL 错误码1213（Deadlock found）或1205（Deadlock timeout）
- 在应用层实现幂等重试逻辑（最多 2~3 次），注意检查业务状态避免重复执行
- 用 SHOW ENGINE INNODB STATUSG 定期分析死锁日志，定位高频冲突 SQL 和表
- 保持事务内 SQL 执行顺序一致（如所有服务按“先更新订单、再更新库存”顺序操作），能显著降低死锁概率
