mysql的repeatable read隔离级别通过mvcc快照读和next-key lock当前读协同防止幻读，但需索引查询、避免混合读、控制事务时长；serializable仅适用于极小数据量且写操作稀疏的场景。
MySQL 默认的 REPEATABLE READ 隔离级别在 InnoDB 引擎下，**已经能解决绝大多数幻读问题**，并不需要盲目升级到 SERIALIZABLE。关键在于理解它怎么工作、什么情况下会失效，以及 Java 应用中如何正确配合使用。
为什么 RR 级别基本能防幻读？
它靠两套机制协同工作：
- 快照读（普通 SELECT）走 MVCC：事务启动后第一次查询生成 Read View，后续所有普通查询都基于这个“时间快照”读取数据 —— 即使其他事务插入了新行，你也看不见，自然不会出现“多出一行”的幻读。
- 当前读（SELECT ... FOR UPDATE / LOCK IN SHARE MODE / UPDATE / DELETE）走 Next-Key Lock：不仅锁住匹配的记录，还锁住这些记录之间的“间隙”。别人想在你查的范围内插入新数据，会被阻塞，从源头上堵住幻行产生。
Java 中怎么设置并确保生效？
Spring Boot + MyBatis/MyBatis-Plus 场景下，不能只改数据库全局配置，得让每个事务真正运行在目标级别上：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 全局默认可保持 MySQL 原生 RR，无需改动；
- 对特别敏感的操作（比如金融核对、库存校验），用
@Transactional(isolation = Isolation.REPEATABLE_READ)显式声明（虽然通常冗余）； - 若真要彻底杜绝任何可能，才考虑
Isolation.SERIALIZABLE，但会强制串行执行，吞吐量明显下降，慎用； - 注意：JDBC 连接池（如 HikariCP）的
connectionInitSql或 Spring 的spring.sql.init.schema-locations不影响运行时事务级别，别混淆。
光调隔离级别还不够，这些细节决定成败
RR 能防幻读，是有前提的：
- 查询必须走索引：Next-Key Lock 只在索引列上生效。如果 WHERE 条件没命中索引（比如对非索引字段查询），InnoDB 会退化为表级锁或锁不住间隙，幻读风险回升；
- 避免混合快照读和当前读：同一个事务里先 SELECT 再 SELECT ... FOR UPDATE，两次读看到的数据视图可能不一致 —— 第一次是快照，第二次是加锁的当前状态，逻辑上就可能“漏掉”或“多出”行；
- 别让事务太久：长时间持有 Next-Key Lock，不仅增加死锁概率，也放大了业务窗口期被干扰的风险；
- INSERT ... SELECT 这类语句要小心：它内部是当前读，会触发间隙锁，但语义上容易被当成“只读”，实际却影响并发插入。
真正需要 SERIALIZABLE 的场景极少
它通过锁整个扫描范围（甚至全表）来杜绝一切并发修改，代价是并发能力骤降。除非你的业务满足：
- 数据量极小（比如配置表、状态机主表）；
- 写操作非常稀疏，读压力也不高；
- 业务逻辑绝对不允许任何“两次查询结果不同”，且无法用应用层校验兜底。
否则，优先优化 SQL（加索引）、拆分事务、用乐观锁或应用层幂等控制，比硬切 SERIALIZABLE 更实际。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
