MySQL高并发事务关键在于用得对、用得稳：控制短事务边界、选READ COMMITTED隔离级别、WHERE走索引精准加锁、捕获死锁错误并幂等重试。

MySQL在高并发场景下使用事务，核心不是“用不用事务”，而是“怎么用得对、用得稳”。关键在于减少锁冲突、控制事务粒度、避免长事务，并配合合理的隔离级别和索引设计。

控制事务边界：短小、明确、及时提交

高并发下最常见问题是长事务——它会持有锁时间过长，阻塞其他事务，甚至拖垮整个数据库。事务应只包裹真正需要原子性的一组操作，且越快结束越好。

• 避免在事务内做网络请求、文件读写、复杂计算等耗时操作
• 不要把用户交互（如等待前端确认）放在事务中
• 用START TRANSACTION显式开启，COMMIT或ROLLBACK必须成对出现，禁止依赖自动提交（autocommit=1）来“假装”事务
• 例如：扣减库存 + 记录订单，这两个操作必须在一个事务里；但生成支付链接、发短信通知这些，应该在事务外异步处理

合理选择隔离级别：读已提交（RC）通常是高并发首选

MySQL默认是可重复读（RR），它通过间隙锁（Gap Lock）防止幻读，但在写多读多场景下容易引发锁竞争和死锁。大多数业务并不需要RR的强一致性，READ COMMITTED既能避免脏读，又大幅减少锁范围，提升并发能力。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 确认业务能否接受“同一事务中两次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 STATUS\G定期分析死锁日志，定位高频冲突SQL和表
• 保持事务内SQL执行顺序一致（如所有服务按“先更新订单、再更新库存”顺序操作），能显著降低死锁概率