mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
[fix]数据可见性算法笔误&内容完善
This commit is contained in:
parent
1fdb7f1702
commit
46146f856d
@ -56,6 +56,24 @@
|
||||
|
||||
### ReadView
|
||||
|
||||
```c
|
||||
class ReadView {
|
||||
/* ... */
|
||||
private:
|
||||
trx_id_t m_low_limit_id; /* 大于这个 ID 的事务均不可见 */
|
||||
|
||||
trx_id_t m_up_limit_id; /* 小于这个 ID 的事务均可见 */
|
||||
|
||||
trx_id_t m_creator_trx_id; /* 创建该 Read View 的事务ID */
|
||||
|
||||
trx_id_t m_low_limit_no; /* 事务 Number, 小于该 Number 的 Undo Logs 均可以被 Purge */
|
||||
|
||||
ids_t m_ids; /* 创建 Read View 时的活跃事务列表 */
|
||||
|
||||
m_closed; /* 标记 Read View 是否 close */
|
||||
}
|
||||
```
|
||||
|
||||
[`Read View`](https://github.com/facebook/mysql-8.0/blob/8.0/storage/innobase/include/read0types.h#L298) 主要是用来做可见性判断,里面保存了 “当前对本事务不可见的其他活跃事务”
|
||||
|
||||
主要有以下字段:
|
||||
@ -65,6 +83,10 @@
|
||||
- `m_ids`:`Read View` 创建时其他未提交的活跃事务 ID 列表。创建 `Read View`时,将当前未提交事务 ID 记录下来,后续即使它们修改了记录行的值,对于当前事务也是不可见的。`m_ids` 不包括当前事务自己和已提交的事务(正在内存中)
|
||||
- `m_creator_trx_id`:创建该 `Read View` 的事务 ID
|
||||
|
||||
**事务可见性示意图**([图源](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/#MVCC-1)):
|
||||
|
||||

|
||||
|
||||
### undo-log
|
||||
|
||||
`undo log` 主要有两个作用:
|
||||
@ -90,7 +112,7 @@
|
||||
|
||||

|
||||
|
||||
不同事务或者相同事务的对同一记录行的修改,会使该记录行的 `undo log` 成为一条链表,链首就是最新的记录,链尾就是最早的旧记录
|
||||
不同事务或者相同事务的对同一记录行的修改,会使该记录行的 `undo log` 成为一条链表,链首就是最新的记录,链尾就是最早的旧记录。
|
||||
|
||||
### 数据可见性算法
|
||||
|
||||
@ -98,7 +120,7 @@
|
||||
|
||||
[具体的比较算法](https://github.com/facebook/mysql-8.0/blob/8.0/storage/innobase/include/read0types.h#L161)如下:[图源](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/#MVCC-1)
|
||||
|
||||

|
||||

|
||||
|
||||
1. 如果记录 DB_TRX_ID < m_up_limit_id,那么表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照之前就提交了,所以该记录行的值对当前事务是可见的
|
||||
|
||||
@ -106,7 +128,7 @@
|
||||
|
||||
3. m_ids 为空,则表明在当前事务创建快照之前,修改该行的事务就已经提交了,所以该记录行的值对当前事务是可见的
|
||||
|
||||
4. 如果 m_up_limit_id <= DB_TRX_ID < m_up_limit_id,表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照的时候可能处于“活动状态”或者“已提交状态”;所以就要对活跃事务列表 m_ids 进行查找(源码中是用的二分查找,因为是有序的)
|
||||
4. 如果 m_low_limit_id <= DB_TRX_ID < m_up_limit_id,表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照的时候可能处于“活动状态”或者“已提交状态”;所以就要对活跃事务列表 m_ids 进行查找(源码中是用的二分查找,因为是有序的)
|
||||
|
||||
- 如果在活跃事务列表 m_ids 中能找到 DB_TRX_ID,表明:① 在当前事务创建快照前,该记录行的值被事务 ID 为 DB_TRX_ID 的事务修改了,但没有提交;或者 ② 在当前事务创建快照后,该记录行的值被事务 ID 为 DB_TRX_ID 的事务修改了。这些情况下,这个记录行的值对当前事务都是不可见的。跳到步骤 5
|
||||
|
||||
@ -210,6 +232,6 @@
|
||||
## 参考
|
||||
|
||||
- **《MySQL 技术内幕 InnoDB 存储引擎第 2 版》**
|
||||
|
||||
- [Innodb 中的事务隔离级别和锁的关系](https://tech.meituan.com/2014/08/20/innodb-lock.html)
|
||||
- [MySQL 事务与 MVCC 如何实现的隔离级别](https://blog.csdn.net/qq_35190492/article/details/109044141)
|
||||
- [InnoDB 事务分析-MVCC](https://leviathan.vip/2019/03/20/InnoDB%E7%9A%84%E4%BA%8B%E5%8A%A1%E5%88%86%E6%9E%90-MVCC/)
|
||||
|
Loading…
x
Reference in New Issue
Block a user