MySQL高并发事务关键在于用得对、用得稳：控制短事务边界、选READ COMMITTED隔离级别、WHERE走索引精准加锁、捕获死锁错误并幂等重试。
MySQL在高并发场景下使用事务，核心不是“用不用事务”，而是“怎么用得对、用得稳”。关键在于减少锁冲突、控制事务粒度、避免长事务，并配合合理的隔离级别和索引设计。
控制事务边界：短小、明确、及时提交
高并发下最常见问题是长事务——它会持有锁时间过长，阻塞其他事务，甚至拖垮整个数据库。事务应只包裹真正需要原子性的一组操作，且越快结束越好。
- 避免在事务内做网络请求、文件读写、复杂计算等耗时操作
- 不要把用户交互（如等待前端确认）放在事务中
- 用START TRANSACTION显式开启，COMMIT或ROLLBACK必须成对出现，禁止依赖自动提交（autocommit=1）来“假装”事务
- 例如：扣减库存 + 记录订单，这两个操作必须在一个事务里；但生成支付链接、发短信通知这些，应该在事务外异步处理
合理选择隔离级别：读已提交（RC）通常是高并发首选
MySQL默认是可重复读（RR），它通过间隙锁（Gap Lock）防止幻读，但在写多读多场景下容易引发锁竞争和死锁。大多数业务并不需要RR的强一致性，READ COMMITTED既能避免脏读，又大幅减少锁范围，提升并发能力。
佳蓝在线销售系统(创业版) 佳蓝在线销售
下载
1、对ASP内核代码进行DLL封装，从而大大提高了用户的访问速度和安全性；2、采用后台生成HTML网页的格式，使程序访问速度得到进一步的提升；3、用户可发展下级会员并在下级购买商品时获得差额利润；4、全新模板选择功能；5、后台增加磁盘绑定功能；6、后台增加库存查询功能；7、后台增加财务统计功能；8、后台面值类型批量设定；9、后台财务曲线报表显示；10、完善订单功能；11、对所有传输的字符串进行安全
- 确认业务能否接受“同一事务中两次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执行顺序一致（如所有服务按“先更新订单、再更新库存”顺序操作），能显著降低死锁概率
