MySQL 默认的事务隔离级别是什么？为什么选择这个级别？

MySQL 默认事务隔离级别详解

【核心定义】

MySQL InnoDB 存储引擎的默认事务隔离级别是 可重复读（REPEATABLE READ），这是为了在保证数据一致性的同时，提供较好的并发性能而设计的平衡选择。

【关键要点】

默认级别确认：MySQL 5.7 及以后版本中，InnoDB 的默认隔离级别为 REPEATABLE READ，可通过 SELECT @@transaction_isolation; 查询确认。
设计目标：在 数据一致性 与 并发性能 之间取得最佳平衡，避免脏读和不可重复读，同时减少锁竞争。
实现机制：通过 多版本并发控制（MVCC） 和 间隙锁（Gap Lock） 共同实现，既保证了读取一致性，又防止了幻读（在 InnoDB 中基本解决）。
兼容性考虑：与 SQL 标准略有不同，InnoDB 的 REPEATABLE READ 通过 Next-Key Lock 机制实际上防止了大部分幻读现象。

【深度推导/细节】

为什么选择 REPEATABLE READ 作为默认级别？

核心矛盾：事务隔离的严格程度与系统并发性能之间的权衡。

逻辑拆解：

Step 1：排除 READ UNCOMMITTED
允许读取未提交数据，会导致脏读，数据一致性无法保证，不适合大多数业务场景。
Step 2：评估 READ COMMITTED
解决了脏读，但存在 不可重复读 问题（同一事务内两次读取同一数据可能结果不同）。
性能影响：每条 SELECT 语句都会生成新的 Read View，需要频繁更新快照，增加系统开销。
Step 3：选择 REPEATABLE READ
- 同一事务内使用 首次读取时建立的 Read View，保证多次读取结果一致
- 通过 Next-Key Lock（记录锁 + 间隙锁）防止其他事务插入新行，基本解决幻读
- 相比 SERIALIZABLE，锁粒度更小，并发度更高
Step 4：排除 SERIALIZABLE
完全串行化执行，锁冲突最多，并发性能最差，仅用于特殊严格要求场景。

MVCC 在 REPEATABLE READ 下的具体实现

-- 事务A
START TRANSACTION;
SELECT * FROM users WHERE id = 1; -- 此时创建 Read View，记录活跃事务列表

-- 事务B（同时执行）
UPDATE users SET name = 'Bob' WHERE id = 1;
COMMIT;

-- 事务A再次查询
SELECT * FROM users WHERE id = 1; -- 仍看到旧数据，因为使用同一个 Read View

【关联/对比】

MySQL 各隔离级别对比

隔离级别	脏读	不可重复读	幻读	锁机制	性能
READ UNCOMMITTED	✓	✓	✓	无锁（快照读）	最高
READ COMMITTED	✗	✓	✓	记录锁	较高
REPEATABLE READ	✗	✗	基本解决	Next-Key Lock	平衡
SERIALIZABLE	✗	✗	✗	范围锁	最低

与 Oracle/PostgreSQL 的差异

Oracle 默认：READ COMMITTED
更注重并发性能，应用层需要处理不可重复读问题
PostgreSQL 默认：READ COMMITTED
但通过 SSI（可串行化快照隔离）提供更强保证
MySQL 选择 REPEATABLE READ：
更适合需要强一致性的 OLTP 场景，减少应用复杂度

『面试官追问』

可能追问的问题：

REPEATABLE READ 如何解决幻读？具体机制是什么？
- 通过 Next-Key Lock（记录锁 + 间隙锁）锁定扫描范围
- 示例：SELECT * FROM users WHERE age > 20 FOR UPDATE 会锁定 age > 20 的所有记录和间隙
MVCC 在 REPEATABLE READ 和 READ COMMITTED 下有何不同？
- REPEATABLE READ：事务开始时创建 Read View，整个事务期间复用
- READ COMMITTED：每条 SELECT 语句都创建新的 Read View
什么情况下 REPEATABLE READ 仍会出现幻读？
- 当使用 普通 SELECT（非锁定读）时，其他事务可以插入新数据
- 解决方案：使用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE

如何修改默认隔离级别？需要考虑什么？

-- 全局修改
SET GLOBAL transaction_isolation = 'READ-COMMITTED';

-- 会话级别修改
SET SESSION transaction_isolation = 'READ-COMMITTED';

考虑因素：应用兼容性、锁竞争变化、一致性要求

为什么 InnoDB 的 REPEATABLE READ 能防止幻读，而标准定义不能？
- SQL 标准中 REPEATABLE READ 不要求防止幻读
- InnoDB 通过 Next-Key Lock 扩展实现了幻读防护，这是 MySQL 的增强特性

版本差异说明

MySQL 5.7 之前：默认隔离级别变量名为 tx_isolation
MySQL 8.0+：变量名改为 transaction_isolation，语义更清晰
InnoDB 的增强：从早期版本就通过 Next-Key Lock 在 REPEATABLE READ 下防止幻读

【最佳实践建议】

默认级别适用场景：大多数 OLTP 系统、需要事务内数据一致的业务（如账户余额查询）
考虑调整为 READ COMMITTED 当：写并发极高、可以接受不可重复读、使用乐观锁控制版本冲突
监控指标：关注 innodb_row_lock_time_avg（平均行锁等待时间），隔离级别调整后应对比该指标变化

总结：MySQL 选择 REPEATABLE READ 作为默认隔离级别，是在数据一致性与系统性能之间做出的工程化权衡。通过 MVCC 机制降低读锁竞争，通过 Next-Key Lock 增强幻读防护，为大多数应用场景提供了”开箱即用”的合理配置。理解这一设计选择背后的权衡逻辑，是掌握 MySQL 事务管理的核心关键。

# MySQL 默认的事务隔离级别是什么？为什么选择这个级别？