MySQL多事务并发需隔离级别、锁机制与事务规范协同：默认REPEATABLE READ适合多数场景，但应据业务选READ COMMITTED或SERIALIZABLE；须走索引以保障行锁，避免长事务与锁升级；配合乐观锁与监控提升并发安全。

MySQL 多事务并发时，核心是靠隔离级别 + 锁机制 + 事务设计规范协同控制，避免脏读、不可重复读、幻读及数据不一致。单纯依赖自动机制容易出问题，关键在理解行为并主动干预。

合理设置事务隔离级别

MySQL 默认是 REPEATABLE READ，适合多数业务场景，但不是万能解：

• 读多写少、强一致性要求高（如账户余额）→ 可用 READ COMMITTED 减少锁范围，配合行锁提升并发度
• 报表类只读查询、允许稍旧数据 → 可设为 READ UNCOMMITTED（慎用，可能读到未提交数据）
• 严格防止幻读且能接受性能损耗 → SERIALIZABLE（会将相关范围加锁，实际中极少全量启用）

通过 SET TRANSACTION ISOLATION LEVEL xxx 在会话或事务开始前设置，避免全局一刀切。

精准使用锁：避免锁升级和长事务

InnoDB 默认用行级锁，但触发条件很关键：

• 必须走索引（主键/唯一/普通索引均可），否则会退化为表锁
• SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 是显式加锁手段，用于读-改场景（如“查余额→扣款”）
• UPDATE/DELETE 带 WHERE 条件时，仅锁定匹配的行；无索引条件 or 范围过大 → 锁定更多行甚至整个索引段

例如：UPDATE orders SET status=2 WHERE user_id=123 AND status=1，若 user_id 无索引，可能锁全表。

缩短事务生命周期，减少锁持有时间

长事务 = 长锁持有 = 并发瓶颈。常见陷阱：

• 在事务内做 HTTP 调用、文件读写、复杂计算等耗时操作
• 开启事务后未及时提交或回滚（尤其异常路径遗漏 ROLLBACK）
• 批量操作一次性处理太多数据（如单事务更新 10 万行）

建议：事务只包裹真正需要原子性的一组 DB 操作，其他逻辑移出事务外；批量任务拆成小批次（如每次 500 行），每批独立事务。

应用层配合：乐观锁与重试机制

对冲突概率低、更新频率不高的场景（如文章点赞数、库存预占），可用版本号或条件更新替代悲观锁：

• 表加 version 字段，更新时校验：UPDATE goods SET stock=stock-1, version=version+1 WHERE id=100 AND version=5
• 检查 ROW_COUNT() 是否为 1，为 0 则说明已被其他事务修改，应用层决定重试或提示失败

比 FOR UPDATE 更轻量，适合高并发读、低频写的业务。