这篇文章主要讲解了“MySQL mvcc奇怪的现象分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“MySQL mvcc奇怪的现象分析”吧!
奇怪的现象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奇怪的现象分析这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
原创文章,作者:3628473679,如若转载,请注明出处:https://blog.ytso.com/202310.html