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 更轻量，适合高并发读、低频写的业务。
不复杂但容易忽略：监控 INFORMATION_SCHEMA.INNODB_TRX 和 SHOW ENGINE INNODB STATUS 能快速发现长事务、锁等待，是调优的第一步。