脏读、不可重复读、幻读不是理论概念，是真实会崩业务的现场
MySQL 需要并发控制，根本原因就一条：
多个事务同时读写同一行或同一范围的数据时，不加约束，结果就不可预测。这不是“可能出错”，而是只要并发量上去、业务逻辑稍复杂（比如查余额→扣款→发通知），立刻触发问题： 脏读：事务 A 把用户余额从
100改成
-50但还没提交，事务 B 读到
-50，直接拒绝提现——而 A 随后回滚了，用户其实有钱，服务却误判 不可重复读：订单服务第一次查库存是
10，中间被秒杀系统减到
0并提交，第二次查变成
0，导致本地缓存和数据库状态对不上，超卖风险陡增 幻读：财务统计“本月新增用户数”，第一次
COUNT(*) WHERE create_time > '2026-01-01'得到
127；刚要生成报表，另一个事务插入一条新用户并提交，再次 COUNT 就变成
128——报表数据自相矛盾
MVCC 不是万能解药，它只管“读”，不管“写”冲突
很多人以为开了 MVCC 就高枕无忧，其实它只解决读写互不阻塞的问题，
写-写和
写-读（当前读）冲突仍需锁来兜底： MVCC 让事务 A 的普通
SELECT看到自己启动时刻的快照，哪怕事务 B 已提交修改，A 也看不到——这避免了不可重复读（在 RR 级别下） 但
UPDATE、
DELETE、
SELECT ... FOR UPDATE、
SELECT ... LOCK IN SHARE MODE这些“当前读”操作，会绕过 MVCC 直接读最新版本，并尝试加锁 如果两个事务同时执行
UPDATE t SET balance = balance - 100 WHERE id = 123，InnoDB 会在主键索引记录上加
X 锁，后到的事务必须等前一个事务提交或回滚才能继续
锁粒度选错，性能会断崖式下跌
锁太粗（比如表锁），并发一上来就排队；锁太细（比如间隙锁没理解透），看似行锁，实际锁住一大片，照样卡死：
没有索引的WHERE条件？InnoDB 只能走聚簇索引全表扫描，
UPDATE会升级为表级意向排他锁（
IX），再对每行加
X 锁——等于事实上的表锁 在
RR隔离级别下，
SELECT * FROM t WHERE age > 25 FOR UPDATE不仅锁住所有
age > 25的现有行，还会锁住这些行之间的“间隙”，防止其他事务插入满足条件的新记录——这就是幻读的锁解决方案，但也会意外锁住本不该碰的范围
INSERT操作虽然不显式加锁，但会自动获取插入意向锁（
INSERT_INTENTION），与间隙锁冲突时一样会等待——别以为“只是插一行”就没事
事务隔离级别不是越高越好，RR 也可能出幻读
MySQL 默认
REPEATABLE READ能防不可重复读，但对幻读的防护有前提： 纯快照读（普通
SELECT）在 RR 下确实看不到新插入的行，所以“感觉不到”幻读 但一旦用了
SELECT ... FOR UPDATE或
UPDATE ... WHERE这类当前读，InnoDB 就必须保证“可串行化语义”，于是用间隙锁+临键锁（next-key lock）封锁范围——这时如果应用没意识到锁范围扩大，就会莫名其妙卡住 真正想彻底杜绝幻读，得用
SERIALIZABLE，但它会让所有
SELECT都隐式加共享锁，写操作基本排队执行，吞吐量骤降，生产环境极少启用
MVCC 和锁是共生关系，不是替代关系；RR 隔离级别下“不出现幻读”的表象，背后是更隐蔽的锁范围扩张——这点在设计分页查询、范围更新、高并发插入场景时，最容易被忽略。
