MySQLmvcc奇怪的现象分析

这篇文章主要讲解了“MySQL mvcc奇怪的现象分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“MySQL mvcc奇怪的现象分析”吧!

创新互联主营神农架林区网站建设的网络公司,主营网站建设方案,重庆APP开发公司,神农架林区h5小程序定制开发搭建,神农架林区网站营销推广欢迎神农架林区等地区企业咨询

奇怪的现象1:

session1:

root@localhost : test 08:43:09> select * from test1;(1)
+---------+------+
| orderid | ID   |
+---------+------+
|       2 | 123  |
+---------+------+
1 row in set (0.00 sec)

root@localhost : test 08:43:14> start transaction;(2)
Query OK, 0 rows affected (0.00 sec)

root@localhost : test 08:43:23> select * from test1;(3)
+---------+------+
| orderid | ID   |
+---------+------+
|       2 | 123  |
+---------+------+
1 row in set (0.00 sec)

root@localhost : test 08:43:27> select * from test1;(5)
+---------+------+
| orderid | ID   |
+---------+------+
|       2 | 123  |
+---------+------+
1 row in set (0.00 sec)

root@localhost : test 08:44:03> update test1 set id=234 where orderid=1;(6)
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

root@localhost : test 08:44:27> select * from test1;(7)
+---------+------+
| orderid | ID   |
+---------+------+
|       1 | 234  |
|       2 | 123  |
+---------+------+
2 rows in set (0.00 sec)

session2:

root@localhost : test 08:43:48> INSERT into test1 values(1,123);(4)
Query OK, 1 row affected (0.01 sec)

奇怪的现象2:

session1:

root@localhost : test 08:46:57> select * from test1;(1)
+---------+------+
| orderid | ID   |
+---------+------+
|       1 | 123  |
|       2 | 123  |
+---------+------+
2 rows in set (0.00 sec)

root@localhost : test 08:47:01> start transaction;(2)
Query OK, 0 rows affected (0.00 sec)

root@localhost : test 08:47:15> select * from test1;(4)
+---------+------+
| orderid | ID   |
+---------+------+
|       1 | 123  |
|       2 | 123  |
|       3 | 123  |
+---------+------+
3 rows in set (0.00 sec)

session2:

insert into test1  values(3,'123');(3)

现象3:

root@localhost : test 08:49:26> start transaction;(1)
Query OK, 0 rows affected (0.00 sec)

root@localhost : test 08:49:28> select * from test1;(2)
+---------+------+
| orderid | ID   |
+---------+------+
|       1 | 123  |
|       2 | 123  |
|       3 | 123  |
+---------+------+
3 rows in set (0.00 sec)

root@localhost : test 08:49:30> select * from test1;(4)
+---------+------+
| orderid | ID   |
+---------+------+
|       1 | 123  |
|       2 | 123  |
|       3 | 123  |
+---------+------+
3 rows in set (0.00 sec)

session2:
root@localhost : test 08:47:43> insert into test1  values(4,'123');(3)
Query OK, 1 row affected (0.01 sec)

现象2和现象3中可以用mvcc中的read-view完美解释:

1、 看不到read view创建时刻以后启动的事务
2、 看不到read view创建时活跃的事务

可能我们熟知的在repeatable-read的隔离级别下,是当一个会话发起dml语句后,在当前会话中如果没有提交当前会话是看不到dml语句操作的结果的!read-view的应用可能很少注意到,像我就是这样。

但是现象1怎么解释呢?

会话1中的insert  trx_id=aa 会话2 中的 trx_id=ac,session2中update之后trx_id=ab ,下面可以看得更清楚

也就是在会话一中update 会话2上的不可见的更新时 会将会话2中的trx_id变为会话1相同的trx_id 所以会话1这个时候能看到的会话2 中不可见数据的更新之后的状态。

感谢各位的阅读,以上就是“MySQL mvcc奇怪的现象分析”的内容了,经过本文的学习后,相信大家对MySQL mvcc奇怪的现象分析这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!


网页名称:MySQLmvcc奇怪的现象分析
标题链接:http://scyanting.com/article/pjscgs.html