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—— 它会忽略该设置，实际降级为
READ 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 —— 新插入 <code>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 的执行计划、索引结构、数据分布来判断。
