曰本做爰l网站,wordpress官方网站,西安网络科技公司,外链兔文章目录 一、数据库并发的场景有三种#xff1a;二、读-写#xff08;一#xff09;3个记录隐藏列字段#xff08;二#xff09;undo 日志#xff08;三#xff09;模拟 MVCC#xff08;四#xff09;一些思考#xff08;五#xff09;Read View 一、数据库并发的场… 文章目录 一、数据库并发的场景有三种二、读-写一3个记录隐藏列字段二undo 日志三模拟 MVCC四一些思考五Read View 一、数据库并发的场景有三种
读-读 不存在任何问题也不需要并发控制读-写 有线程安全问题可能会造成事务隔离性问题可能遇到脏读幻读不可重复读写-写 有线程安全问题可能会存在更新丢失问题比如第一类更新丢失第二类更新丢失(后面 补充)
二、读-写
多版本并发控制 MVCC 是一种用来解决 读-写冲突 的无锁并发控制。 为事务分配单向增长的事务ID为每个修改保存一个版本版本与事务ID关联读操作只读该事务开始 前的数据库的快照。 所以 MVCC 可以为数据库解决以下问题
在并发读写数据库时可以做到在读操作时不用阻塞写操作写操作也不用阻塞读操作提高了数 据库并发读写的性能同时还可以解决脏读幻读不可重复读等事务隔离问题但不能解决更新丢失问题
理解 MVCC 需要知道三个前提知识
3个记录隐藏字段undo 日志Read View
一3个记录隐藏列字段 DB_TRX_ID 6 byte最近修改( 修改/插入 )事务ID记录创建这条记录/最后一次修改该记录的事 务ID DB_ROLL_PTR : 7 byte回滚指针指向这条记录的上一个版本简单理解成指向历史版本就 行这些数据一般在 undo log 中 DB_ROW_ID : 6 byte隐含的自增ID隐藏主键如果数据表没有主键 InnoDB 会自动以 DB_ROW_ID 产生一个聚簇索引 补充实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除而是删除flag变了 假设测试表结构是
mysql create table if not exists student(
name varchar(11) not null,
age int not null
);
mysql insert into student (name, age) values (张三, 28);
Query OK, 1 row affected (0.05 sec)
mysql select * from student;
-------------
| name | age |
-------------
| 张三 | 28 |
-------------
1 row in set (0.00 sec)上面描述的意思是 我们目前并不知道创建该记录的事务ID隐式主键我们就默认设置成null1。第一条记录也没有其他 版本我们设置回滚指针为null。
二undo 日志
MySQL 将来是以服务进程的方式在内存中运行。之前所讲的所有机制索引事务隔离性日志等都是在内存中完成的即在 MySQL 内部的相关缓冲区中保存相关数据完成各种判断操作。然后在合适的时候将相关数据刷新到磁盘当中的。所以我们这里理解undo log简单理解成就是 MySQL 中的一段内存缓冲区用来保存日志数据的就行。
三模拟 MVCC
现在有一个事务10(仅仅为了好区分)对student表中记录进行修改(update)将name(张三)改成 name(李四)。 事务10,因为要修改所以要先给该记录加行锁。 修改前现将改行记录拷贝到undo log中所以undo log中就有了一行副本数据。(原理就是写 时拷贝) 所以现在 MySQL 中有两行同样的记录。现在修改原始记录中的name改成 ‘李四’。并且修改原始 记录的隐藏字段 DB_TRX_ID 为当前 事务10 的ID, 我们默认从 10 开始之后递增。而原始记录的回 滚指针 DB_ROLL_PTR 列里面写入undo log中副本数据的地址从而指向副本记录既表示我的 上一个版本就是它。 事务10提交释放锁。 备注此时最新的记录是’李四‘那条记录。 现在又有一个事务11对student表中记录进行修改(update)将age(28)改成age(38)。 事务11,因为也要修改所以要先给该记录加行锁。该记录是那条 修改前现将改行记录拷贝到undo log中所以undo log中就又有了一行副本数据。此时新的 副本我们采用头插方式插入undo log。 现在修改原始记录中的age改成 38。并且修改原始记录的隐藏字段 DB_TRX_ID 为当前 事务11 的 ID。而原始记录的回滚指针 DB_ROLL_PTR 列里面写入undo log中副本数据的地址从而指向副 本记录既表示我的上一个版本就是它。 事务11提交释放锁。 这样我们就有了一个基于链表记录的历史版本链。所谓的回滚无非就是用历史数据覆盖当前数 据。上面的一个一个版本我们可以称之为一个一个的快照。
四一些思考
上面是以更新upadte主讲的,如果是delete呢一样的别忘了删数据不是清空而是设置flag 为删除即可。也可以形成版本。
如果是insert呢因为insert是插入也就是之前没有数据那么insert也就没有历史版本。但是 一般为了回滚操作insert的数据也是要被放入undo log中如果当前事务commit了那么这个undo log 的历史insert记录就可以被清空了。 总结一下也就是我们可以理解成update和delete可以形成版本链insert暂时不考虑。
那么select呢
首先select不会对数据做任何修改所以为select维护多版本没有意义。不过此时有个问题 就是 select读取是读取最新的版本呢还是读取历史版本 当前读读取最新的记录就是当前读。增删改都叫做当前读select也有可能当前读比如select lock in share mode(共享锁), select for update 这个好理解我们后面不讨论。
快照读读取历史版本(一般而言)就叫做快照读。(这个我们后面重点讨论)
我们可以看到在多个事务同时删改查的时候都是当前读是要加锁的。那同时有select过来如果也要读取最新版(当前读)那么也就需要加锁这就是串行化。但如果是快照读读取历史版本的话是不受加锁限制的。也就是可以并行执行换言之提高了效率即MVCC的意义所在。
历史版本的数据不可修改
那么是什么决定了select是当前读还是快照读呢隔离级别! 那为什么要有隔离级别呢 事务都是原子的。所以无论如何事务总有先有后。
但是经过上面的操作我们发现事务从begin-CURD-commit是有一个阶段的。也就是事务有执行前执行中执行后的阶段。但不管怎么启动多个事务总是有先有后的。 那么多个事务在执行中CURD操作是会交织在一起的。那么为了保证事务的“有先有后”是不是应该让不同的事务看到它该看到的内容这就是所谓的隔离性与隔离级别要解决的问题。 先来的事务应不应该看到后来的事务所做的修改呢?
五Read View
Read View就是事务进行 快照读 操作的时候生产的 读视图 (Read View)在该事务执行的快照读的那一 刻会生成数据库系统当前的一个快照记录并维护系统当前活跃事务的ID(当每个事务开启时都会被 分配一个ID, 这个ID是递增的所以最新的事务ID值越大)。 Read View 在 MySQL 源码中,就是一个类本质是用来进行可见性判断的。 即当我们某个事务执行快照 读的时候对该记录创建一个 Read View 读视图把它比作条件,用来判断当前事务能够看到哪个版本的 数据既可能是当前最新的数据也有可能是该行记录的 undo log 里面的某个版本的数据。
下面是 ReadView 结构,但为了减少负担我们简化一下
class ReadView {
// 省略...
private:
/** 高水位大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id
/** 低水位小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;
/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;
/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
/** 配合purge标识该视图不需要小于m_low_limit_no的UNDO LOG
* 如果其他视图也不需要则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
// 省略...
};
m_ids; //一张列表用来维护Read View生成时刻系统正活跃的事务ID
up_limit_id; //记录m_ids列表中事务ID最小的ID(没有写错)
low_limit_id; //ReadView生成时刻系统尚未分配的下一个事务ID也就是目前已出现过的事务ID的
最大值1(也没有写错)
creator_trx_id //创建该ReadView的事务IDMySql学习的最后一节课感觉数据库真的是这几门里面最简单的了虽然说刚开始配置环境的时候也是很头疼但是好在自己坚持下来了继续努力还有接下来的redises…,c是永远学不完的…
