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能快速发现长事务、锁等待，是调优的第一步。
