MySQL事务隔离级别与幻读问题深度解析
事务隔离级别概述
MySQL数据库提供四种事务隔离级别，用于平衡并发性能与数据一致性。不同隔离级别对各类并发问题的处理能力存在差异。
隔离级别对照表
| 隔离级别 | 编号 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|---|
| READ-UNCOMMITTED | 0 | 存在 | 存在 | 存在 |
| READ-COMMITTED | 1 | 不存在 | 存在 | 存在 |
| REPEATABLE-READ | 2 | 不存在 | 不存在 | 存在 |
| SERIALIZABLE | 3 | 不存在 | 不存在 | 不存在 |
MySQL默认采用REPEATABLE-READ级别，通过MVCC机制实现可重复读取。SERIALIZABLE级别虽然能完全避免幻读，但以牺牲并发性能为代价。
查看与设置隔离级别
-- 查看当前隔离级别
SELECT @@global.tx_isolation, @@tx_isolation;
-- 设置全局隔离级别
SET @@global.tx_isolation = 'REPEATABLE-READ';
-- 设置会话级隔离级别
SET @@session.tx_isolation = 'READ-COMMITTED';
深入理解幻读现象
常见误解
许多人将幻读理解为"同一事务中两次SELECT结果集不同"，这实际上是错误的。这种情况属于不可重复读，仅出现在READ-UNCOMMITTED和READ-COMMITTED级别。在MySQL默认的REPEATABLE-READ级别下，得益于MVCC机制，同一事务的多次读取结果通常是一致的。
幻读的本质
幻读的核心特征是：事务通过读取判断某记录不存在，准备插入时，却发现该记录已存在，导致插入失败。这种"看到的数据与实际不符"的现象，正是幻读的体现。
简单来说，幻读就是事务在"读取-判断-操作"的逻辑链条中，读取阶段确认不存在的记录，在写入阶段却发现已存在，如同幻影一般。
幻读场景演示
假设存在表 users，包含 id（主键）字段。
事务A（主事务）：
-- 步骤1：查询id为1的记录
SELECT * FROM users WHERE id = 1;
-- 结果：空，判定记录不存在
-- 步骤3：尝试插入id为1的记录
INSERT INTO users VALUES (1, 'big cat');
-- 结果：主键冲突，执行失败
-- 步骤4：再次查询验证
SELECT * FROM users WHERE id = 1;
-- 结果：仍为空（MVCC机制）
事务B（并发事务）：
-- 步骤2：在事务A之前插入id为1的记录
INSERT INTO users VALUES (1, 'big cat');
在REPEATABLE-READ级别下执行流程：
- 事务A执行步骤1，确认id=1的记录不存在
- 事务B执行步骤2，插入id=1的记录并提交
- 事务A执行步骤3，尝试插入时发现主键冲突
- 事务A执行步骤4，再次查询结果仍为空
对于事务A而言，步骤1读取的结果无法支撑步骤3的业务操作，这就是幻读。事务A会疑惑："我明明读取不到这条记录，为什么无法插入？"
REPEATABLE-READ级别下防止幻读
使用排他锁
在REPEATABLE-READ级别下，通过对SELECT操作显式加排他锁（X锁），可以避免幻读。这正是SERIALIZABLE级别隐式执行的操作。
-- 对查询结果加排他锁
SELECT id FROM users WHERE id = 1 FOR UPDATE;
FOR UPDATE会锁定：
- 若记录存在：锁定该行记录
- 若记录不存在：锁定相应的间隙（next-key lock）
其他事务无法在该索引范围内进行任何写操作，从而杜绝幻读。
记录不存在时的锁机制
即使查询结果为空，FOR UPDATE仍会加锁。InnoDB的行锁锁定的是索引，而非记录本身。
具体流程演示：
-- 事务A：查询id=1（不存在）并加锁
START TRANSACTION;
SELECT id FROM users WHERE id = 1 FOR UPDATE;
-- 此时会锁定id=1附近的间隙
-- 事务B：尝试插入id=1
INSERT INTO users VALUES (1, 'big cat');
-- 被阻塞，等待事务A释放锁
-- 事务A：插入id=1
INSERT INTO users VALUES (1, 'big cat');
-- 执行成功（事务B仍被阻塞）
COMMIT;
-- 事务B解除阻塞，但因主键冲突执行失败
SERIALIZABLE级别分析
SERIALIZABLE级别通过强制串行化执行，完全避免幻读。该级别下，InnoDB会自动对所有读取操作加锁，无需显式使用FOR UPDATE。
-- 设置为SERIALIZABLE级别
SET SESSION tx_isolation = 'SERIALIZABLE';
-- 事务A：自动加锁
START TRANSACTION;
SELECT * FROM users WHERE id = 2;
-- InnoDB隐式添加X锁和间隙锁
-- 事务B：尝试插入
INSERT INTO users VALUES (2, 'new record');
-- 被阻塞
-- 事务A：插入同一条记录
INSERT INTO users VALUES (2, 'new record');
-- 执行成功
COMMIT;
-- 事务B解除阻塞，主键冲突
优点：事务安全，无需手动加锁
缺点：并发性能差，不适合高并发场景
总结与建议
隔离级别选择策略
- REPEATABLE-READ：默认级别，在安全与性能间取得平衡。多数业务场景下不会发生幻读，可根据实际需求选择性加锁。
- SERIALIZABLE：适用于对数据一致性要求极高、并发要求较低的场景。
InnoDB锁机制要点
- 行锁锁定的是索引，而非记录本身
- 相同索引值的记录会同时被锁定，可能引发索引竞争
- 记录存在时加行锁，记录不存在时加间隙锁
- 合理设计业务SQL，使用主键或唯一索引可减少锁冲突
理解幻读的本质后，开发者可根据业务场景灵活选择防护策略，在保证数据安全的前提下最大化并发性能。
