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奇怪的現象分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！