MVCC是InnoDB自动启用的并发控制机制，通过隐藏列、Undo Log和Read View实现快照读，RC每次SELECT建新ReadView，RR仅首次建并复用，使读不加锁、读写不互阻。
Java 应用里操作 MySQL InnoDB 事务时，MVCC 不是 Java 代码直接写的逻辑，而是由 InnoDB 引擎在底层自动启用的并发控制机制——它让多个事务能“各看各的版本”，读不加锁、读写不互阻，从而提升并发性能。理解它，关键不是写代码，而是知道 Java 发起的 SQL 在什么条件下触发 MVCC、它怎么影响查询结果、以及为什么某些隔离级别下行为不同。
Java 中事务启动方式决定 MVCC 是否生效
MVCC 只对 Read Committed（RC） 和 Repeatable Read（RR） 隔离级别起作用。Java 中通过以下方式开启事务，才真正进入 MVCC 工作范围：
- 显式开启：
connection.setAutoCommit(false)后执行 SQL，再手动commit()或rollback() - 使用 Spring 的
@Transactional注解（默认传播行为REQUIRED，且未显式指定isolation时，走 MySQL 默认的 RR 级别） - 避免长事务：事务持续时间越长，InnoDB 需保留的旧版本（undo log）越多，可能拖慢 purge 线程，甚至撑爆 undo 表空间
MVCC 如何让 Java 查询“看到一致的数据快照”
InnoDB 给每行数据加了两个隐藏字段：DATA_TRX_ID（创建事务 ID） 和 DATA_ROLL_PTR（指向 undo log 的回滚指针）。当 Java 执行 SELECT 时，InnoDB 不直接读最新行，而是根据当前事务的 ReadView（读视图） 去比对版本：
- 在 RR 级别：事务第一次执行 SELECT 时生成一个 ReadView，后续所有 SELECT 都复用它 → 同一事务内多次查同一行，结果一定相同（解决不可重复读）
- 在 RC 级别：每次 SELECT 都新建 ReadView → 能看到其他事务已提交的新版本 → 同一事务内两次查，结果可能不同（允许不可重复读）
- 无论哪种级别，SELECT 都不会加锁（快照读），而
UPDATE/DELETE会加行锁（当前读），并可能触发新版本写入
Java 开发中容易踩坑的 MVCC 表现
看似透明的 MVCC，在实际编码中会暴露为具体现象，需结合事务边界和 SQL 类型判断：
立即学习“Java免费学习笔记（深入）”；
-
“查不到刚插入的数据”：若在同一个事务里先
INSERT再SELECT，能查到；但若跨事务，且插入事务未提交，RC/RR 下都查不到（MVCC 过滤掉未提交版本） -
“更新丢失”仍可能发生：MVCC 解决脏读、不可重复读，但不解决更新丢失（Lost Update）。例如两个事务同时查余额为 100，各自+50 后更新，最终可能是 150 而非 200 —— 需靠
SELECT ... FOR UPDATE加锁或应用层 CAS 控制 -
幻读在 RR 下并未完全消失：MVCC 保证“同条件查不到新插入行”，但若用
SELECT ... FOR UPDATE或修改涉及间隙（如WHERE id > 10），InnoDB 会用 Next-Key Lock（间隙锁+记录锁）阻止插入，这才是 RR 解决幻读的实际手段，不是纯靠 MVCC
调试与验证 MVCC 行为的小技巧
不必依赖 Java 日志，直接连 MySQL 查看底层状态更直观：
- 查当前隔离级别：
SELECT @@transaction_isolation; - 查活跃事务：
SELECT * FROM information_schema.INNODB_TRX;关注TRX_STARTED和TRX_STATE - 模拟 MVCC 效果：开两个命令行窗口，一个事务 INSERT 后不提交，另一个窗口在 RC/RR 下执行 SELECT —— 观察是否可见
- 注意 autocommit：Spring Boot 默认开启
autocommit=true，单条 SQL 是独立事务，MVCC 仅在多语句事务中体现明显
