当前位置：首页 > news >正文

MySQL RR (Repeatable Read) 隔离级别规则细节

news 来源：原创 2025/6/2 14:05:22

准备

测试表：

CREATE TABLE `transaction_test`
(`id`    int,`value` int,`mtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`id`)
) ENGINE = InnoDB;

mysql设置：

transaction_isolation = REPEATABLE-READ
autocommit = ON

事务指令：

BEGIN  开启事务
COMMIT  提交
ROLLBACK  回滚

1：事务基础

A B两个连接

A:
BEGIN;
insert into transaction_test(id, value) values (1, 1);B:
select * from transaction_test where id = 1;   
-- 查不到未提交的修改A:
COMMIT;B:
select * from transaction_test where id = 1;   
-- 能查到已提交的修改，mtime是执行insert时的时间

2：读操作，快照读

A:
insert into transaction_test(id, value) values (1, 1);B:
BEGIN;
select * from transaction_test where id = 1 or id = 2;
-- 查到id=1A:
insert into transaction_test(id, value) values (2, 2);B:
select * from transaction_test where id = 1 or id = 2;
--仍只查到id=1
--RR是读快照，第一次select时为整个库创建一致性快照，后续select都基于这个快照
--即创建快照后，其他事务的写操作(增、删、改)均对本次事务不可见

3：写操作，当前读，幻读

A:
BEGIN;
select * from transaction_test where id = 1;
--返回空B:
insert into transaction_test(id, value) values (1, 1);A:
select * from transaction_test where id = 1;
--返回空，为第一次select时的快照update transaction_test set value = 2 where id = 1;
--1 row affected ，写操作会取当前已commit的数据版本（即当前读，而非快照读），所以能修改 B insert 的数据select * from transaction_test where id = 1;
--查到id=1，自己事务的写操作对自己可见，所以此时能看到id=1这行数据
--上次查询读不到id=1的行，本次能读到，这一问题称为幻读
--注意：如果上述 update 改为 set value = 1，不改变数据的值，则后续仍然读不到

4：SELECT 后 INSERT 的竞态条件

A:
BEGIN;
select * from transaction_test where id = 1;
-- 返回空B:
insert into transaction_test(id, value) values (1, 1);A:
-- 检查select结果是否存在，如果不存在，执行插入
insert into transaction_test(id, value) values (1, 1);
-- Duplicate entry '1' for key 'PRIMARY'   插入失败

5：更新丢失

A:
BEGIN;
SELECT value FROM transaction_test WHERE id = 1; -- 读快照，得到100B:
BEGIN;
SELECT value FROM transaction_test WHERE id = 1; -- 读快照，仍为100A:
UPDATE transaction_test SET value = 100 + 10 WHERE id = 1; -- 写为110
COMMIT;B:
UPDATE transaction_test SET value = 100 + 20 WHERE id = 1; -- 写为120
COMMIT;

6：无丢失更新，排他锁

-- value初始为100
A:
UPDATE transaction_test SET value = value + 10 WHERE id = 1; 
-- 写为110，UPDATE会加排他锁(X Lock)，为行锁B:
UPDATE transaction_test SET value = value + 20 WHERE id = 1;
-- 此时A持有id=1的行锁，B等待A:
COMMIT;  
-- 提交value=110的值B:
--A提交会释放锁，此时重新执行B的UPDATE，写操作为当前读，value由110更新为130
COMMIT;
-- 提交value=130的值

7：间隙锁，避免幻读

A:
BEGIN;
select * from transaction_test where id < 5 for update;
--执行 SELECT ... FOR UPDATE 或 UPDATE、DELETE 语句时，会为条件涉及的范围加间隙锁(Gap Lock)
--即使范围中没有实际数据，也会锁定间隙。B:
insert into transaction_test(id, value) values (1, 1);
--尝试在锁定范围(id=1)内写数据，会阻塞A:
-- 检查select结果是否存在，如果不存在，执行插入
insert into transaction_test(id, value) values (1, 1);
--插入成功
commitB:
--A commit 释放锁，此时重新执行B的插入，插入失败

8：死锁检测

InnoDB死锁检测默认开启，innodb_deadlock_detect=ON

A:
BEGIN;
update transaction_test set value = 1 where id = 1;
-- 持有id=1的行锁B:
BEGIN;
update transaction_test set value = 4 where id = 2;
-- 持有id=2的行锁A:
update transaction_test set value = 2 where id = 2;
-- 阻塞，等待事务B的锁
COMMIT;B:
update transaction_test set value = 3 where id = 1;
-- 阻塞，等待事务A的锁  -> 死锁
-- 当检测到死锁时，InnoDB 会主动回滚代价最小的事务，打破循环等待
-- 此时B回滚，A执行成功，回滚的事务会收到 ERROR 1213: Deadlock found
COMMIT;