在并发环境中，多个事务同时操作相同数据可能引发脏读、不可重复读、幻读三类经典问题。SQL 标准为此定义了四种隔离级别，Spring 通过 Isolation 枚举对这些级别进行了封装，并在不同数据库上完成了映射与适配。理解这层对应关系，是正确配置事务行为、避免数据一致性事故的前提。
6.4.1 Spring 中的隔离级别枚举
org.springframework.transaction.annotation.Isolation 共定义了五个值，直接映射到 SQL 标准的四个级别，外加一个“使用数据库默认值”的特殊设定：
| Spring Isolation | SQL 标准级别 | 含义 |
|------------------|--------------|------|
| DEFAULT | — | 使用底层数据库的默认隔离级别（MySQL 默认为 REPEATABLE_READ，Oracle/PostgreSQL 默认为 READ_COMMITTED） |
| READ_UNCOMMITTED | READ UNCOMMITTED | 允许读取未提交的变更，存在脏读、不可重复读、幻读 |
| READ_COMMITTED | READ COMMITTED | 只能读取已提交的数据，杜绝脏读，但不可重复读和幻读仍可能发生 |
| REPEATABLE_READ | REPEATABLE READ | 确保同一事务中多次读取同一行结果一致，杜绝脏读和不可重复读，但幻读仍可能发生（InnoDB 通过间隙锁在特定场景下避免了幻读） |
| SERIALIZABLE | SERIALIZABLE | 最高隔离级别，事务完全串行化执行，杜绝所有并发问题，代价是性能大幅下降 |
值得注意的是，Spring 并没有“发明”新的隔离级别，DEFAULT 以外的四个值完全对应 SQL 标准。选择 DEFAULT 时，实际上是将隔离级别的控制权交还给数据库，便于在不同部署环境下保持灵活性。
6.4.2 与主流数据库的映射关系
虽然 SQL 标准统一了隔离级别的定义，但各数据库在实现细节和默认行为上存在差异。Spring 在底层使用 JDBC 时，会调用 Connection.setTransactionIsolation(int level) 方法设置隔离级别，其常量值也是 JDBC 规范中定义的标准值。下表总结了几种常见数据库对这四个级别的支持情况和默认值：
| 数据库 | 默认隔离级别 | 支持的隔离级别 | 备注 |
|--------|--------------|----------------|------|
| MySQL (InnoDB) | REPEATABLE READ | 全部4种 （SERIALIZABLE 会退化为快照读+共享锁） | 与 SQL 标准不同，InnoDB 的 REPEATABLE READ 通过间隙锁（Gap Lock）规避了大部分幻读场景 |
| PostgreSQL | READ COMMITTED | 全部4种 | PostgreSQL 中的 REPEATABLE READ 实际实现了快照隔离，也能防止幻读 |
| Oracle | READ COMMITTED | READ COMMITTED, SERIALIZABLE（不支持 READ UNCOMMITTED 和 REPEATABLE READ） | Oracle 的 SERIALIZABLE 使用快照隔离实现，不会阻塞写操作 |
| SQL Server | READ COMMITTED | 全部4种（SERIALIZABLE 使用范围锁） | 可通过 READ_COMMITTED_SNAPSHOT 数据库选项调整 READ COMMITTED 的行为 |
| H2 | READ COMMITTED | 全部4种 | 嵌入式数据库，测试时很常用 |
在应用中使用 @Transactional(isolation = Isolation.READ_UNCOMMITTED) 时，Spring 会要求 JDBC 驱动设置对应的隔离级别。如果数据库本身不支持该级别（例如 Oracle 不支持 READ UNCOMMITTED），JDBC 驱动通常会静默升级到其支持的最接近级别（如 Oracle 会升级为 READ COMMITTED），而不是直接抛出异常。这种行为看似友好，却可能导致测试环境与实际生产环境行为不一致，需要特别留意。
6.4.3 实际工作中的选择策略与注意事项
1. 优先使用 DEFAULT，必要时显式指定
绝大多数业务场景下，数据库自身的默认隔离级别是经过广泛验证的最优选择。例如 MySQL 的 REPEATABLE READ 配合间隙锁能很好地平衡一致性与性能；PostgreSQL 和 Oracle 的 READ COMMITTED 则提供了足够的并发度。除非你确切知道当前业务面临的并发问题类型，并需要在事务层面覆盖数据库默认值，否则不要轻易修改隔离级别。
2. 常见场景的隔离级别推荐
- 报表查询、只读分析：
READ_UNCOMMITTED或READ_COMMITTED，通常不需要高一致性，脏读可以接受时可采用最低级别换取性能。 - 普通 OLTP 业务：保持数据库默认（
DEFAULT），或显式设置为READ_COMMITTED，平衡一致性与吞吐。 - 涉及多行一致性快照（如对账、资金核对）：可考虑
REPEATABLE_READ，确保在同一个事务中多次读取某个结果集的一致性。 - 金融类操作或需要绝对串行化的场景：
SERIALIZABLE，但要评估性能影响并做好失败重试机制（因为极易发生锁冲突和死锁）。
3. 隔离级别不能替代业务幂等与锁设计
隔离级别解决的是数据库层面的并发可见性问题，它无法弥补业务逻辑缺陷。例如，即使使用了 SERIALIZABLE，也无法阻止用户在两个请求中重复提交订单——那需要业务层面的分布式锁或幂等键。把隔离级别当作解决所有并发问题的银弹，是实践中最常见的误区。
4. 注意传播行为与隔离级别的协同
在一个调用链上，如果外层事务已存在，内层事务修改隔离级别是否生效，取决于具体的事务传播行为。大多数数据库的 JDBC 驱动不允许在一个已存在的事务中更改隔离级别（即 Connection.setTransactionIsolation 只能在事务开始前调用）。因此，如果在 @Transactional(propagation = Propagation.REQUIRES_NEW) 的内部方法上设置了不同的隔离级别，新的隔离级别会生效，因为新事务会使用新的连接；但如果传播行为是 REQUIRED（加入已有事务），对隔离级别的修改尝试通常会被忽略。
5. 验证隔离级别是否生效
不要仅凭注解就假设隔离级别已正确设置。在实际项目中，可以借助以下 SQL 语句在事务执行过程中进行自检：
- MySQL：
SELECT @@transaction_isolation; - PostgreSQL：
SHOW transaction_isolation; - Oracle：
SELECT s.sid, s.serial#, bit.name FROM v$transaction t, v$session s, v$transaction_enqueue te, (SELECT ...) ...（较复杂，通常通过DBMS_TRANSACTION包观察）
或在集成测试中使用 DataSource 工具类获取当前连接并断言其隔离级别值。
综上，Spring 的事务隔离级别只是 SQL 标准的轻量封装，其行为本质依然取决于底层数据库的实现。理解这层对应关系，并在实际选择时遵循“数据库优先、业务驱动、实测验证”的原则，才能真正用好事务隔离机制，既不过度设计，也不掉入并发陷阱。