MySQL mvcc奇怪的现象分析

这篇文章主要讲解了“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奇怪的现象分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！