高并发下mysql事务需“短、准、慎、稳”：事务要短（只包读写校验与变更），锁要准（靠索引控制粒度），隔离要慎（优先RC减少间隙锁），兜底要稳（设超时、重试、降级）。
高并发下使用 MySQL 事务，核心不是“能不能用事务”，而是“如何让事务又快又稳不拖垮数据库”。关键在于缩短事务持有锁的时间、减少锁冲突范围、避免长事务和死锁，同时合理利用隔离级别与索引。
事务要短：只包真正需要原子性的操作
长事务是高并发下的头号杀手——它会持续占用行锁、间隙锁甚至表锁，阻塞其他请求。比如用户下单，不要把“查库存→扣库存→生成订单→发消息→更新积分”全塞进一个事务里。
- 只把必须一起成功或一起失败的操作放进事务：通常是“读取校验 + 写入变更”这两步，例如select … for UPDATE后紧跟UPDATE；
- 日志记录、消息发送、缓存更新等非核心一致性操作，移到事务外异步处理；
- 避免在事务内调用外部 http 接口或执行耗时计算。
锁要准：靠索引+明确语句类型控制锁粒度
MySQL 的行锁（如 RECORD LOCK）只在有可用索引时生效。全表扫描或 WHERE 条件没走索引，会升级为表锁或锁住大量无关行，极大加剧冲突。
- 确保 SELECT … FOR UPDATE 和 UPDATE/delete 的 WHERE 条件命中索引（最好是唯一索引或主键）；
- 避免 SELECT … FOR UPDATE 带 ORDER BY 或 LIMIT 且未走索引，否则可能锁住整个范围；
- 用 EXPLaiN 确认执行计划，尤其注意 type 是否为 const/ref，key 是否显示用了索引。
隔离要慎：读已提交（RC）通常比可重复读（RR）更友好
MySQL 默认的 RR 隔离级别会启用间隙锁（Gap Lock），防止幻读，但也显著增加锁冲突概率。在多数业务场景（如秒杀扣库存、账户余额更新），只要能接受“读已提交”，就优先选 RC。
- RC 下只有记录锁，没有间隙锁，锁范围更小，冲突更少；
- RC 下不会出现因间隙锁导致的“明明没查到记录却加锁失败”的情况；
- 切换前需确认业务能否容忍不可重复读（例如两次 SELECT 同一行得到不同值），多数写多读少场景影响极小。
兜底要稳：超时、重试、降级缺一不可
再好的设计也扛不住突发流量或慢 SQL。必须在应用层做防御：
- 给事务设置合理超时（如 innodb_lock_wait_timeout=10），避免一个卡住的事务拖垮整个连接池；
- 对常见冲突错误（如 Deadlock found、Lock wait timeout）做指数退避重试（最多 2–3 次）；
- 核心链路（如支付、下单）设计降级开关：当 DB 响应延迟突增或失败率超标时，可临时切到预扣减+异步核验模式。
不复杂但容易忽略。