mysql中事务的隔离级别与并发控制

MySQL默认隔离级别REPEATABLE READ通过MVCC+间隙锁防幻读，但仅对当前读生效；普通SELECT是快照读、不加锁；依赖可重复读语义需显式加锁；READ COMMITTED禁用间隙锁、幻读风险高；SELECT ... FOR UPDATE会锁范围而非单行。

MySQL 默认隔离级别是 REPEATABLE READ，但不是所有场景都安全

MySQL 8.0+ 默认使用 REPEATABLE READ，它通过 MVCC + 间隙锁（Gap Lock）防止幻读，但仅对「当前读」（如 SELECT ... FOR UPDATE、UPDATE、DELETE）生效；普通 SELECT 是快照读，不加锁，也不受间隙锁影响。这意味着：两个事务并发执行普通查询时，可能看到彼此未提交的修改（取决于是否已开启事务及是否触发一致性视图），但不会因插入新行而产生幻读——前提是用了当前读。

• 如果业务依赖「可重复读」语义做判断（比如先查再 insert 防重），必须显式用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE，否则快照读会绕过锁机制
• READ COMMITTED 下间隙锁被禁用（除外键检查和唯一索引冲突），幻读风险上升，但非阻塞程度更高，适合高并发只读+短更新场景
• MySQL 不支持真正的 READ UNCOMMITTED —— 它会忽略该设置，实际降级为 RE

  

  AD COMMITTED

SELECT ... FOR UPDATE 在 REPEATABLE READ 下会锁住范围，不只是命中行

这是最容易踩坑的地方：即使 WHERE 条件走索引，SELECT ... FOR UPDATE 也会基于聚簇索引加间隙锁，锁定「满足条件的记录区间」，而非单条记录。例如表 t(id PK, name) 中有 (1,'a'), (5,'e'), (10,'j')，执行 SELECT * FROM t WHERE id > 3 AND id ，会锁住 (1,5)、(5,10) 两个间隙，以及记录 5 —— 新插入 id=4 或 id=7 都会被阻塞。

• 若只想锁具体行，确保 WHERE 精确匹配唯一索引（如 WHERE id = 5），且该值存在；否则仍可能升级为范围锁
• 没有索引的 WHERE 条件会导致全表扫描+全表行锁，等价于表级锁，务必避免
• 在 READ COMMITTED 下，同样语句只锁命中的行，不锁间隙，但代价是可能出现幻读

并发更新同一行时，UPDATE 的加锁行为取决于 WHERE 和索引

MySQL 的 UPDATE 默认是当前读，一定加锁。但锁类型（记录锁 / 间隙锁 / 临键锁）由执行计划决定：

• WHERE 匹配唯一索引且值存在 → 加 Record Lock（仅锁该行）
• WHERE 匹配唯一索引但值不存在 → 加 Gap Lock（锁前后间隙）
• WHERE 匹配非唯一索引或范围条件 → 加 Next-Key Lock（记录锁 + 间隙锁组合）
• WHERE 不走索引 → 全表扫描，每行加记录锁，同时可能锁间隙，性能灾难

典型错误是写 UPDATE user SET status=1 WHERE name='xxx' 却没给 name 建索引，导致并发更新时大量锁等待甚至死锁。

死锁检测开销不可忽视，innodb_deadlock_detect 关闭后需靠超时兜底

MySQL 默认开启死锁检测（innodb_deadlock_detect=ON），会在每次加锁时做环路检测。高并发短事务下，这个检测本身会成为瓶颈。有些场景（如热点账户余额更新）会考虑关掉它，改用 innodb_lock_wait_timeout（默认 50 秒）兜底。

• 关闭后，事务只能靠超时退出，无法及时感知死锁，应用层必须处理 Lock wait timeout exceeded 错误并重试
• 更稳妥的做法是：控制事务粒度（越小越好）、按固定顺序访问多行（如总是先更新 user 再更新 order）、避免在事务中做 RPC 或 sleep
• 用 SHOW ENGINE INNODB STATUS 可查最近死锁详情，关键看 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 和 *** (2) HOLDS THE LOCK(S): 两段

隔离级别不是银弹，锁行为才是并发问题的真正源头。调低级别不一定提升性能，反而可能引入业务逻辑漏洞；盲目加锁又容易拖垮吞吐。得结合具体 SQL 的执行计划、索引结构、数据分布来判断。