实验准备
创建脚本
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(16) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL,
`age` int(11) NULL DEFAULT NULL,
`addr` varchar(256) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
事务执行脚本
- 事务1
# 事务1
-- 查询事务隔离级别：
select @@tx_isolation;
-- 设置数据库的隔离级别
set session transaction isolation level read committed;
#没有修改之前的值为杭州
SELECT * FROM tab_user;
START TRANSACTION
#T1执行
UPDATE user SET addr = '重庆' WHERE id = 1;
#T2执行
UPDATE user SET addr = '成都' WHERE id = 1;
#T7执行
COMMIT;
- 事务2
# 事务02
-- 查询事务隔离级别：
select @@tx_isolation;
-- 设置数据库的隔离级别
set session transaction isolation level read committed;
START TRANSACTION
#T4执行
UPDATE user SET name = '西安' WHERE id = 1;
#T5执行
UPDATE user SET name = '广东' WHERE id = 1;
#T9执行
COMMIT;
- 事务3
# 事务3
-- 查询事务隔离级别：
select @@tx_isolation;
-- 设置数据库的隔离级别
set session transaction isolation level read committed;
START TRANSACTION
# T6时刻执行
SELECT * FROM user WHERE id = 1;
# T8时刻执行
SELECT * FROM user WHERE id = 1;
# T10时刻执行
SELECT * FROM user WHERE id = 1;
COMMIT;
执行表记录
| 时间 | 事务1 | 事务2 | 事务3 |
|---|---|---|---|
| T1 | begin T | begin T | begin T |
| T2 | 更新为重庆 | ||
| T3 | 更新为成都 | ||
| T4 | 更新为西安 | ||
| T5 | 更新为广东 | ||
| T6 | 执行查询,查询addr属性 | ||
| T7 | 提交事务 | ||
| T8 | 执行查询,查询addr属性 | ||
| T9 | 提交事务 | ||
| T10 | 执行查询查询addr属性 |
结果分析
RC
我们假设这三个事务的ID分别是1,2,3
T6时刻的查询版本对应情况如下:
这个时候执行查询生产ReadView
| m_low_limit_id | m_ids | m_up_limit_id | m_creator_trx_id |
|---|---|---|---|
| 1 | 12 | 3 | 3 |
这时候广东这个版本不符合可见要求因为它在m_ids中所以看下一个版本，发现西安同样不满足要求，接着成都，重庆都不符合要求所以最终取的是杭州这个版本，因为这个是之前的事务做的更改，事务id小于最小的限制。
T8时刻
这个时候执行查询生产ReadView
| m_low_limit_id | m_ids | m_up_limit_id | m_creator_trx_id |
|---|---|---|---|
| 2 | 2 | 3 | 3 |
由于事务1提交了生成的时候1不在m_ids中，所以找到成都已经是可以见的版本，所以最终结果为成都。
T10时刻
这个时候执行查询生产ReadView
| m_low_limit_id | m_ids | m_up_limit_id | m_creator_trx_id |
|---|---|---|---|
| 3 | 3 | 3 |
由于事务1，2都提交了生成的时候1，2不在m_ids中，所以找到广东已经是可以见的版本，所以最终结果为广东。
从上面的结果来看，每次查询都生产RadView保证了事务提交的数据在其它事务中可见，也就是保证了RC隔离性。
RR
如果我们将事务的上面每个事务的隔离性设置为repeatable read
这个时候，只有在在事务三种只有第一次查询T6时刻才会生成ReadView
| m_low_limit_id | m_ids | m_up_limit_id | m_creator_trx_id |
|---|---|---|---|
| 1 | 12 | 3 | 3 |
后面T8,T10都不生产ReadView,那么每次查询可见的版本都是杭州，这样就保证了事务RR隔级别。
