MySQL RR隔离级别的更新冲突战略

发布时间：2022-03-25 23:41:36 所属栏目：MySql教程来源：互联网

导读：对于事务的隔离级别，MySQL中默认是RR, Oracle中默认是RC,两个事务隔离级别存在着很大的差别，而换句话说，就算是RR的事务隔离级别级别，同是关系型数据库MySQL,SQLServer,postgreSQL也会有一些差别。所以隔离级别的部分还是值得花一些时间来总结一下。之

    对于事务的隔离级别，MySQL中默认是RR, Oracle中默认是RC,两个事务隔离级别存在着很大的差别，而换句话说，就算是RR的事务隔离级别级别，同是关系型数据库MySQL,SQLServer,postgreSQL也会有一些差别。所以隔离级别的部分还是值得花一些时间来总结一下。

之前看到过丁奇大师的一篇文章，是分析InnoDB的在隔离级别RR下的一个“诡异”现象。读来受益匪浅，丁大师不光明理而且还能改动代码解决问题，实在佩服，我在自己的环境中也做了一些简单的测试和分析。

首先是初始化基础数据，我们开启两个窗口，创建一个测试表，插入两条记录。

create table t (id int not null, name varchar(10) ) engine=innodb ;
insert into t values(1,'name1'),(3,'name3');
   整个过程虽然是两个窗口，但是操作是一个串行的过程。

首先看下RR本身的现象，会话1开启一个事务，会话2插入一条记录，在会话1中查询应该还是2条数据。

会话2插入一条记录，默认提交。
> insert into t values(4,'name4');
Query OK, 1 row affected (0.00 sec)

这个过程中，如果在会话1中查看数据，应该还是2条，这也是RR本身对的含义。
会话 1:
> select *from t;
+----+-------+
| id | name |
+----+-------+
| 1 | name1 |
| 3 | name3 |
+----+-------+
2 rows in set (0.00 sec)

我们继续做一个update, id=4的记录是刚刚在会话2中插入的，在此处变更，从结果来看还是产生了一行数据的变化，这是一个“诡异”的地方。

> Update t set name= 'name_test' where id = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
而接下来的地方就是问题的关键了，我们再次查询就输出了3行记录，原来id=4,name='name4'的记录在会话1里面被修改成了id=4,name='name_test'

> select *from t;
+----+-----------+
| id | name      |
+----+-----------+
| 1 | name1     |
| 3 | name3     |
| 4 | name_test |
+----+-----------+
3 rows in set (0.00 sec)

   所以这就是更新冲突的策略了，目前的MySQL在RR隔离级别下的实现是这样。而按照我们预期的要求，应该在会话1的事务内是对会话2的变更不可见的。

   这一点上，在5.7中的结果也是如此，在5.1的版本中的update的输出效果会有一些差别。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

mysql重创某个用户账号	Linux运维定会的MySQL
MySQL视图存储步骤与	MySQL的server_uuid取