0.铺垫
- 在RR级别的时候，多个事件的update，多个事件的insert，多个事件的delete，是否会有加锁征象？
- 征象效果是，update，insert，delete之间是会有加锁征象的
- 但是select和这些操作是不辩论的
- 这就是通过读写锁(锁有行锁或者表锁)+MVCC完成隔离性
- 数据库并发的场景有三种
- 读-读：不存在任何题目，也不需要并发控制
- 读-写：有线程安全题目，大概会造成事件隔离性题目，大概遇到脏读，幻读，不可重复读
- 写-写：有线程安全题目，大概会存在更新丢失题目，比如第一类更新丢失，第二类更新丢失
1.初识MVCC
- 多版本并发控制(MVCC)是一种用来解决 读-写辩论 的无锁并发控制
- 为事件分配单向增长的事件ID，为每个修改保存一个版本，版本与事件ID关联，读操作只读该事件开始前的数据库的快照
- 以是 MVCC 可以为数据库解决以下题目
- 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
- 同时还可以解决脏读，幻读，不可重复读等事件隔离题目，但不能解决更新丢失题目
- 明白 MVCC 需要知道三个前提知识
- 3个记录隐藏字段
- undo 日志
- Read View
2.三个记录隐藏列字段
1.是什么？
- 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变了
2.示例
- 假设测试表布局是：
- mysql> create table if not exists student(
- name varchar(11) not null,
- age int not null
- );
- mysql> insert into student (name, age) values ('张三', 28);
- mysql> select * from student;
- +--------+-----+
- | name | age |
- +--------+-----+
- | 张三 | 28 |
- +--------+-----+
- 上面描述的意思是：
- 目前并不知道创建该记录的事件ID，隐式主键，就默认设置成null，1
- 第一条记录也没有其他版本，设置回滚指针为null
nameage**DB_TRX_ID(**创建该记录的事件ID)**DB_ROW_ID(**隐式主键)**DB_ROLL_PTR(**回滚指针)张三28null1null
3.undo日志
- 这里不想细讲，但是有一件事情得说清楚， MySQL 未来是以服务进程的方式在内存中运行
- 之前所讲的全部机制：索引，事件，隔离性，日志等，都是在内存中完成的
- 即：在 MySQL 内部的干系缓冲区中，保存干系数据，完成各种判断操作，然后在合适的时候，将干系数据刷新到磁盘当中的
- 以是，这里明白undo log，简朴明白成，就是 MySQL 中的一段内存缓冲区，用来保存日志数据的就行
4.模仿MVCC
- 如今有一个事件10，对student表中记录进行修改(update)：将name(张三)改成name(李四)
- 事件10，因为要修改，以是要先给该记录加行锁
- 修改前，先将该行记录拷贝到undo log中
- 以是，undo log中就有了一行副本数据(原理就是写时拷贝)
- 以是如今 MySQL 中有两行同样的记录
- 如今修改原始记录中的name，改成 ‘李四’，而且修改原始记录的隐藏字段 DB_TRX_ID 为当前 事件10 的ID
- 而原始记录的回滚指针 DB_ROLL_PTR 列，内里写入undo log中副本数据的地点，从而指向副本记录
- 事件10提交，释放锁
- TIPS：此时，最新的记录是’李四’那条记录
- 如今又有一个事件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提交，释放锁
- 如许，就有了一个基于链表记录的历史版本链
- 所谓的回滚，无非就是用历史数据，覆盖当前数据
- 上面的一个一个版本，可以称之为一个一个的快照
5.思考
- 上面是以更新(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操作是会交织在一起的
- 那么，为了保证事件的"有先有后"，是不是应该让差异的事件看到它该看到的内容，这就是所谓的隔离性与隔离级别要解决的题目
- 先来的事件，应不应该看到后来的事件所做的修改呢?
- 那么，如何保证，差异的事件，看到差异的内容呢？也就是如何如何实现隔离级别？
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
