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