数据库:MySQL。【很多主流数据库都使用了MVCC,比如MySQL的InnoDB引擎、PostgreSQL、Oracle】
MVCC,全称Multi-Version Concurrency Control,即多版本并发控制。是数据库管理系统中的一种并发控制方法。
MVCC的基本原理: 它通过保存数据的历史版本来实现,这样读操作不会被写操作阻塞,写操作也不会被读操作阻塞。这样的话,提高了并发性能。比如说,当一个事务开始读取数据时,它会看到数据库在某个时间点的快照,之后即使其他事务修改了数据,这个事务看到的还是旧版本的数据,直到它提交或者回滚。
不同的隔离级别(如读已提交、可重复读、串行化)在MVCC中的实现方式不同。例如,在读已提交级别下,每次读取都会获取最新的快照,而可重复读则是在事务开始时确定快照,后续读取都基于这个快照,从而避免不可重复读的问题。
- 当前读:像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读,为什么叫当前读?就是它读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。
- 快照读:像不加锁的select操作就是快照读,即不加锁的非阻塞读;快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读;之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于多版本并发控制,即MVCC,可以认为MVCC是行锁的一个变种,但它在很多情况下,避免了加锁操作,降低了开销;既然是基于多版本,即快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本
MVCC就是为了实现读-写冲突不加锁,而这个读指的就是快照读, 而非当前读,当前读实际上是一种加锁的操作,是悲观锁的实现
当前读 悲观锁; 快照读 乐观锁?
数据库不知道的秘密。
每行记录除了我们自定义的字段外,还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段
- DB_TRX_ID:6byte,最近修改(修改/插入)事务ID:记录创建这条记录/最后一次修改该记录的事务ID ---------【事务ID】
- DB_ROLL_PTR:7byte,回滚指针,指向这条记录的上一个版本(存储于rollback segment里) -----------------【回滚指针】
- DB_ROW_ID:6byte,隐含的自增ID(隐藏主键),如果数据表没有主键,InnoDB会自动以DB_ROW_ID产生一个聚簇索引 ----------【隐藏主键】
- 实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除,而是删除flag变了 --------【删除标记】
DB_TRX_ID
(事务ID)和 DB_ROLL_PTR
(回滚指针)维护多个版本。有这样一张表,里面有记录。
id | name | age | DB_TRX_ID | DB_ROLL_PTR |
---|---|---|---|---|
1 | Alice | 25 | 100 | 0x0000 |
初始版本由事务 txid=100
提交生成;DB_ROLL_PTR
指向旧版本(初始为 NULL
)。
这个时候有两个事务来了。
UPDATE user SET age=26 WHERE id=1
。SELECT * FROM user WHERE id=1
。事务A 更新数据,InnoDB引擎,会为这行数据创建一个新版本,并修改 DB_TRX_ID=200
,DB_ROLL_PTR
指向旧版本(事务100提交的版本)。
这个时候,还没有A事务还没有提交,新版本(V2)还未提交,旧版本(V1)仍然存在。
id | name | age | DB_TRX_ID | DB_ROLL_PTR 【这个是新版本V2】
---|-------|-----|-----------|------------
1 | Alice | 26 | 200 | 0x1234(指向旧版本V1)
丨丨
丨丨
↓
id | name | age | DB_TRX_ID | DB_ROLL_PTR 【这个是旧版本V1】
---|-------|-----|-----------|------------
1 | Alice | 25 | 100 | 0x0000
然后,事务B读取数据,事务B 启动时会生成一个 ReadView,记录当前活跃事务的 ID 列表。假设此时只有事务A(txid=200)未提交,活跃事务列表为 [200]
事务B 根据 ReadView 判断数据版本的可见性:
DB_TRX_ID
小于当前事务的 txid
,且该事务已提交,则可见。DB_TRX_ID=200
),但事务B 的 ReadView 显示 txid=200
是活跃的(未提交),因此 V2 不可见。DB_ROLL_PTR
)找到旧版本 V1(DB_TRX_ID=100
),判断 100 且已提交,因此返回 V1 的数据:
故,事务B读到的如下:
id | name | age
---|-------|-----
1 | Alice | 26
可以看到上述读写,好像没有加锁。。
InnoDB 判断数据版本是否可见的逻辑如下:
DB_TRX_ID
小于当前事务的 txid
,且该事务已提交 → 可见,【怎么看提交了没有呢?看事务的活跃列表】。DB_TRX_ID
等于当前事务的 txid
→ 可见(事务可以看到自己的修改)。DB_TRX_ID
大于当前事务的 txid
→ 不可见(属于未来的修改)。DB_TRX_ID
在事务的 ReadView 活跃列表中 → 不可见(该事务尚未提交)。MVCC 通过维护数据多版本和 ReadView 机制,实现读写不阻塞和高并发:
这种机制在保证事务隔离性的同时,极大提升了数据库并发性能。
MySQL 中的 undo log、redo log 和 binlog 是三种核心日志,各自承担不同的职责,共同保障数据库的事务性、持久性和高可用性
下面三个是参考deepseek的解释。
作用
工作机制
INSERT
、UPDATE
或 DELETE
时,InnoDB 会将修改前的数据保存到 undo log。见上面的mvcc。
作用
工作机制
binlog_format
:STATEMENT
、ROW
、MIXED
)。sync_binlog
参数控制刷盘频率。我来举个例子:
-- 事务C: 删除一行数据
BEGIN;
DELETE FROM users WHERE id = 1;
COMMIT;
-- 提交后,binlog 记录该 DELETE 语句(或行变化)。从库读取 binlog 并重放,保持数据一致性。
作用
工作机制
innodb_flush_log_at_trx_commit
控制:
1
(默认):每次提交都刷盘,保证崩溃恢复不丢数据。0
或 2
:延迟刷盘,性能更高但可能丢失部分数据。我来举个例子:
-- 事务B: 插入一条新数据
BEGIN;
INSERT INTO users (id, name) VALUES (2, 'Bob');
COMMIT;
-- 提交时,redo log 记录插入操作的物理页修改,之后数据可能还未写入磁盘。
-- 若此时崩溃,重启后根据 redo log 恢复该插入操作。
以更新操作为例子:
prepare
状态并刷盘。 写入 binlog 并刷盘。将 redo log 标记为 commit
状态(两阶段提交,保证一致性)。1. 为什么需要 redo log 和 binlog 两种日志?
2. undo log 会被删除吗?
3. binlog 和 redo log 的写入顺序?
事务提交时,先写 redo log(prepare) → 再写 binlog → 最后写 redo log(commit)。
这是为了确保崩溃恢复时,binlog 和 redo log 的一致性(两阶段提交)。
undo log:保障事务的原子性和 MVCC。
redo log:保障事务的持久性和崩溃恢复。
binlog:保障数据可复制性和逻辑恢复。
参与评论
手机查看
返回顶部