脏读、不可重复读、幻读是真实崩业务的并发问题：脏读导致误判（如余额为负后回滚），不可重复读引发超卖，幻读造成报表矛盾；MVCC仅解决快照读冲突，写操作仍依赖锁；锁粒度不当或隔离级别误用会加剧性能与一致性风险。
脏读、不可重复读、幻读不是理论概念，是真实会崩业务的现场
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 隔离级别下“不出现幻读”的表象，背后是更隐蔽的锁范围扩张——这点在设计分页查询、范围更新、高并发插入场景时，最容易被忽略。
