织梦网站修改,html源码网,网站开发中文摘要,网页的设计与制作目录
一 前景导入
1 当前读
2 快照读
二 MVCC
1 隐藏字段
2 UndoLog 回滚日志
(1 UndoLog日志
(2 UndoLog版本链
3 Read View
面试八股 介绍一下MVCC 一 前景导入
1 当前读
可使当前事务读取的是最新版本的数据#xff0c;读取时还要保证其他并发事务不能修改当中…目录
一 前景导入
1 当前读
2 快照读
二 MVCC
1 隐藏字段
2 UndoLog 回滚日志
(1 UndoLog日志
(2 UndoLog版本链
3 Read View
面试八股 介绍一下MVCC 一 前景导入
1 当前读
可使当前事务读取的是最新版本的数据读取时还要保证其他并发事务不能修改当中记录会对读取的记录进行加锁。 SELECT ... LOCK IN SHARE MODE (共享锁/S锁) SELECT ... FOR UPDATE (排他锁/X锁) UPDATE、INSERT、DELETE 操作(自动加排他锁)
2 快照读
简单的select(不加锁)就是快照读读取的是记录数据的可见版本有可能是历史数据不加锁。
快照读本质上就是使用MVCC机制访问数据的历史版本
隔离级别快照读行为当前读行为Read Committed每次 SELECT 都生成新的快照(能看到其他事务已提交的修改)始终读取最新已提交版本并加锁Repeatable Read事务中第一个 SELECT 语句建立快照后续读取都基于此快照(看不到后续修改)始终读取最新已提交版本并加锁Serializable快照读退化为当前读(所有 SELECT 自动转为 SELECT ... LOCK IN SHARE MODE)正常当前读行为
二 MVCC
概念MVCC全称多版本并发控制。
MVCC允许多个事务同时读取同一行数据但是确保了数据版本是当前事务开启之前的版本。其他事务修改但是看见的版本还是修改之前的
1 隐藏字段
在 InnoDB 的 MVCC 实现中每条记录都包含三个关键隐藏字段它们共同构建了多版本控制的基石
字段名大小作用是否必选DB_TRX_ID 事务ID6 字节记录最后修改该行的事务 ID 总是存在DB_ROLL_PTR 回滚指针7 字节指向 Undo Log 中上一个版本的指针构成版本链 总是存在DB_ROW_ID6 字节隐式自增主键仅当无主键时生成 条件存在
2 UndoLog 回滚日志
(1 UndoLog日志
概念回滚日志用于记录数据被修改前的信息
作用是数据库实现事务原子性和多版本并发控制的核心机制 场景化描述 当事务需要回滚或一致性读时内存中可能存在未提交的修改。 重启后或事务内Undo Log 能提供旧数据版本用于 撤销未提交的操作回滚 构造历史快照MVCC 非阻塞读 (2 UndoLog版本链
Undo Log 版本链的核心价值正是通过精准的指针定位实现对历史版本的精确访问。
3 Read View
读视图用于决定事务能看到哪些版本的数据。本质上是事务启动时对数据库系统状态的一次快照解决了并发读写当中的数据可见性问题。 Read View 包含四个关键字段
字段名描述作用m_ids生成 Read View 时活跃事务ID列表未提交的事务判断数据版本是否由未提交事务创建min_trx_id活跃事务中的最小事务ID加速判断事务ID min_trx_id 一定可见max_trx_id系统预分配的下一个事务ID非当前最大ID判断事务ID ≥ max_trx_id 一定不可见creator_trx_id创建该 Read View 的事务ID当前事务自身ID避免看到自己未提交的修改
读已提交这个隔离级别当中在每一个select 语句执行前都会生成一个ReadView。导致出现不可重复读的现象可能出现两次读取数据不同的情况。
可重复读是执行第一条select时生成一个ReadView然后整个业务期间都在使用这个ReadView。读取的数据始终相同无视其他事务的提交。
举个例子
-- 事务A (RC级别)
BEGIN; -- trx_id100 (事务A被分配ID100)-- 第一次查询 (创建ReadView1)
SELECT balance FROM accounts WHERE id1; -- 返回1000
/*
ReadView1状态:m_ids [100] -- 活跃事务ID列表 (当前只有事务A)min_trx_id 100 -- 最小活跃事务ID (m_ids中的最小值)max_trx_id 101 -- 下一个将分配的事务ID (当前最大事务ID1)creator_trx_id 100 -- 创建此ReadView的事务ID可见性判断过程:假设数据行初始db_trx_id90 (小于min_trx_id)90 min_trx_id(100) → 可见 → 返回1000
*/-- 事务B (trx_id101) 启动并提交UPDATE accounts SET balance900 WHERE id1;-- 修改后数据行:-- db_trx_id 101 (最后修改事务ID)-- db_roll_ptr → 指向旧版本(trx_id90, balance1000)COMMIT; -- 事务B提交从活跃事务列表移除-- 第二次查询 (创建新ReadView2)
SELECT balance FROM accounts WHERE id1; -- 返回900
/*
ReadView2状态:m_ids [100] -- 活跃事务ID列表 (事务B已提交只剩事务A)min_trx_id 100 -- 最小活跃事务ID (仍是100)max_trx_id 102 -- 下一个将分配的事务ID (101已使用)creator_trx_id 100 -- 创建者事务ID可见性判断过程:当前行db_trx_id1011. 101 ! creator_trx_id(100) → 非当前事务修改2. 101 min_trx_id(100) 且 101 max_trx_id(102) → 在[mins, max)范围内3. 检查m_ids[100] → 101不在其中 → 已提交 → 可见返回当前版本数据900
*/
可见性判断规则优先级 首先检查db_trx_id creator_trx_id当前事务自身修改 然后检查db_trx_id min_trx_id在ReadView创建前已提交 再检查db_trx_id max_trx_id在ReadView创建后启动的事务读取快照之后有事务过来修改了但是快照读取的是那一瞬间的值故才会出现大于max预分配的情况 最后检查范围min_trx_id db_trx_id max_trx_id 在m_ids中 → 未提交 → 不可见 不在m_ids中 → 已提交 → 可见
三 面试八股 介绍一下MVCC
首先我想介绍的是MVCC是什么MVCC全称多版本并发控制核心思想如同字面意思为数据维护多个版本而并非直接覆盖。
其次再说说其功能其主要解决的是读写之间冲突而导致的并发性能问题。他让不同的事务在不同的隔离级别能看见不同的隔离级别主要是RC与RR这两种隔离级别RC是在每一次读取之前都会生成一个ReadView快照而RR是只在第一次读取之前生成一个ReadView快照RR则在一次事务当中就不会出现不可重复读的情况而RC则会出现不可重复读的现象因为其允许其他事务对其进行写的操作导致读取的数据可能会出现不同呆滞出现不可重复读 核心版本链ReadViewundolog 这里说到了ReadView就涉及其原理部分了这里就不得不提到一个隐藏字段存储在数据行当中的db_trx_id最后修改数据的事务id在读取时会拿这个事务id与ReadView当中的字段进行对比四个字段创建当前ReadView事务的id生成ReadView时活跃的最小事务id生成ReadView时活跃的事务id的列表生成ReadView时预分配的下一个事务id 首先检查db_trx_id creator_trx_id当前事务自身修改可见 然后检查db_trx_id min_trx_id在ReadView创建前已提交可见 再检查db_trx_id max_trx_id在ReadView创建后启动的事务不可见 最后检查范围min_trx_id db_trx_id max_trx_id 在m_ids中 → 未提交 → 不可见 不在m_ids中 → 已提交 → 可见
以上是对事务版本的判断判断结束后如果是可见的那么就直接返回该版本的数据作为查询结果但是如果不可见那么就需要用到版本链回溯到之前的版本获取行数据的db_roll_ptr回滚指针指针指向上一个版本在undolog回滚日志当中具体位置
