MySQL 事务隔离级别全解析：为什么默认是 Repeatable Read？

👋 程序员的日常开发中，最容易遇到的坑是什么？
不是写 SQL 报错，而是——并发场景下，数据为什么“莫名其妙变了”？

答案就在 事务隔离级别。
今天我们来聊：

• • MySQL 有哪些事务隔离级别？
• • 它们会带来哪些并发问题？
• • MySQL 默认用的是什么？为什么？

一、事务隔离级别是什么？

一句话解释：
事务隔离级别决定了并发事务之间“看不看得见彼此的数据变化”。

在高并发场景下，不同隔离级别会导致不同的数据一致性效果。

二、四大隔离级别（由低到高）

💡 三个关键并发问题回顾：

• • 脏读（Dirty Read）：读到未提交事务的数据。
• • 不可重复读（Non-repeatable Read）：同一事务内两次查询到的结果不一致。
• • 幻读（Phantom Read）：同一范围查询，第二次结果多/少了行。

三、MySQL 的默认隔离级别

👉 在 MySQL（InnoDB 存储引擎） 中，默认事务隔离级别是：Repeatable Read（可重复读）。

为什么不是 Oracle 默认的 Read Committed？

• • InnoDB 通过 MVCC（多版本并发控制） + 间隙锁（Gap Lock） 机制，可以在 Repeatable Read 下避免幻读。
• • 这样既保证了数据一致性，又能保持比较高的并发性能。

换句话说：MySQL 的默认隔离级别 比 Oracle 的更严格一些，能减少“奇怪数据”的出现。

四、开发实战：怎么查看 & 设置隔离级别？

🔎 查看当前隔离级别：

SELECT @@transaction_isolation;

⚙️ 修改隔离级别：

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL REPEATABLE READ;

• • SESSION：只影响当前会话。
• • GLOBAL：影响新建会话（已连接的不受影响）。

五、怎么选隔离级别？

• • 读多写少，允许一点延迟 → Read Committed 就够了，性能更优。
• • 电商下单、金融转账 → 必须用 Repeatable Read 或 Serializable，保证数据安全。
• • 大规模并发读写 → Repeatable Read（MySQL 默认）通常最佳平衡。