事务
2019-08-18 15:34:49 41 举报AI智能生成
登录查看完整内容
mysql_事务&Redo日志&Undo日志&MVCC
作者其他创作
大纲/内容
要么全做，要么全不做
原子性(atomic)
两次状态转换应该是互不影响的;要保证其他的状态转换不会影响本次状态转换。
隔离性(Isolation)
如果数据库中的数据全部符合现实世界的约束，则称符合一致性
例如转账案例中，不仅要保证转账的账户总的余额不变。 要还保证转账后余额不能出现负数
一致性(Consistency)
当现实世界的一个状态转换后，这个转换的结果将永久保留
持久性(Durability)
事务的ACID
事务对应的数据库操作正在执行过程中时，我们就说该事务处在活动的状态。
活动的（active）
当事务中的最后一个操作执行完成，但由于操作都在内存中执行（保存在Buffer Pool的free链表中），所造成的影响并没有刷新到磁盘时，我们就说该事务处在部分提交的状态。
部分提交的（partially committed）
当事务处在活动的或者部分提交的状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续执行，或者人为的停止当前事务的执行，我们就说该事务处在失败的状态。
失败的（failed）
如果事务执行了半截而变为失败的状态，比如我们前边唠叨的狗哥向猫爷转账的事务，当狗哥账户的钱被扣除，但是猫爷账户的钱没有增加时遇到了错误，从而当前事务处在了失败的状态，那么就需要把已经修改的狗哥账户余额调整为未转账之前的金额，换句话说，就是要撤销失败事务对当前数据库造成的影响。书面一点的话，我们把这个撤销的过程称之为回滚。当回滚操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我们就说该事务处在了中止的状态。
中止的（aborted）
当一个处在部分提交的状态的事务将修改过的数据都同步到磁盘上之后，我们就可以说该事务处在了提交的状态。
提交的（committed）
事务的状态机
开启事务
提交事务
手动回滚事务
关闭自动提交
1. 定义或修改数据库对象的数据定义语言 （DDL）
如ALTER USER、CREATE USER、DROP USER、GRANT、RENAME USER、REVOKE、SET PASSWORD等语句
2. 隐式使用或修改mysql数据库中的表
3. 事务控制或关于锁定的语句
LOAD DATA
4. 加载数据的语句
START SLAVE、STOP SLAVE、RESET SLAVE、CHANGE MASTER TO等语句
5. 关于MySQL复制的一些语句
隐式提交
设置回滚点
删除回滚点
事务语法
InnoDB
支持
MyISAM
不支持
存储引擎对事务的支持
事务简介
如何在服务器出现故障时保证数据的持久性（比如很多修改的数据可能还保留在Buffer Pool的脏页面中）
解决的问题
在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘
刷新一个完整的数据页太浪费了
随机IO刷起来比较慢
问题
粗暴的办法
没有必要在事务提交时将涉及的脏页全部刷新到磁盘。只需要把修改了哪些东西记录一下（比如在系统表空间的第100号页面的偏移量处的值更新为ABC）然后在事务提交的时候，把redo日志刷新到磁盘即可。然后在系统崩溃重启时按照上面所记录的步骤重新更新数据页
redo日志占用的空间非常小
redo日志是顺序写入磁盘的
特点
redo日志基本概念
redo日志通用结构
只在某个页面的某个偏移量处修改了几个字节的值
如为了维护隐含主键递增，而需维护系统表空间的MAX ROW ID字段
栗子
简单的redo日志类型
redo日志格式
一条语句可能涉及更新多个页面
表中包含多个索引，一条INSERT语句可能更新多棵B+树
针对一颗B+树，可能更新叶子节点，页可能更新内节点，页可能创建新的页面
可能更新数据页的File Header、Page Header、Page Directory信息
可能修改的页面
方案一：在每个修改的地方都记录一条redo日志
方案二：将整个页面的第一个被修改的字节到最后一个修改的字节之间的所有数据当成是一条物理redo日志的具体数据
初始方案
栗子:一个Insert操作
弊端：占用的空间很大
在系统崩溃重启时，并不能直接根据这些日志的记载，将页面的某个偏移量恢复成某个数据。而是需要调用一些事先准备好的函数，执行完这些函数后才能将页面恢复成系统崩溃前的样子。
怎么做？
把能恢复一条数据的必要信息保存下来
关键
插入一条非紧凑行记录（如Reduant）
MLOG_REC_INSERT
插入一条紧凑行格式的记录
MLOG_COMP_REC_INSERT
创建一个存储紧凑行格式记录的页面的redo日志类型
MLOG_COMP_PAGE_CREATE
删除一条使用紧凑行格式记录的redo日志类型
MLOG_COMP_REC_DELETE
表示从某条给定记录开始删除页面中的一系列使用紧凑行格式记录的redo日志类型
MLOG_COMP_LIST_START_DELETE
删除一系列记录直到某条记录
MLOG_COMP_LIST_END_DELETE
压缩数据页的redo日志类型
MLOG_ZIP_PAGE_COMPRESS
常见类型
新的redo日志类型（逻辑日志）
复杂的redo日志格式类型
需要保证原子性的操作必须以组的形式来记录redo日志，在进行系统崩溃重启时，针对某个组的redo日志要么把全部的日志都恢复掉，要么一条也不恢复
更新Max Row ID属性产生的redo日志是不可分割的
向聚簇索引对应B+树的页面中插入一条记录时产生的redo日志是不可分割的
向某个二级索引对应B+树的页面中插入一条记录时产生的redo日志是不可分割的
还有其他的一些页面的访问操作时产生的redo日志是不可分割的
Mini-Transaction以组的形式写入redo日志
保存日志的页面redo log block
解决磁盘过慢的redo日志缓冲区
redo日志写入log buffer(以mtr为单位)
redo日志（上）
log buffer空间不足时
为了保证持久性
事务提交时
后台线程不停的刷刷刷
正常关闭服务器时
redo日志刷盘时机
如何调节文件组所在的目录、每个日志文件的大小、指定redo日志文件个数
redo日志文件组
redo日志文件格式
为了记录已经写入(到log buffer)的日志量
目的
每一组由mtr生成的redo日志都有一个唯一的LSN值与其对应，LSN值越小，说明redo日志产生的越早
特性
LSN
lsn
buf_free
标志当前日志写到的最大LSN
flushed_to_disk_lsn
buf_next_to_write
标志将log buffer中的日志写入到磁盘
log_buffer中几个重要的指针
lsn值与redo日志文件偏移量的对应关系
只有当flush链表中的脏页刷新到磁盘时，相应的redo日志才能被覆盖
flush链表中的LSN
检查点checkpoint
checkpoint_lsn
log file中的几个重要指针
读取log file中的控制信息checkpoint_lsn
确定恢复的起点
遍历每一个block header，看它是否有没有被写满。 LOG_BLOCK_HDR_DATA_LEN=512
确定恢复的终点
将表空间，页号作为key， redo日志作为value。那么恢复的时候可以一次性将一个页面修复完毕，减少大量的随机IO
1. 使用哈希表提高速度
因为检查点之后可能有脏页被刷新到磁盘了，那这些页面就不需要恢复，需要跳过
如何跳过？ 在redo日志中可以定位数据页。而数据页中有属性记录newest_modification。拿它与checkpoint_lsn相比，如果前者大，说明在check_point之后，该脏页被刷新到了磁盘。因此这些页面就可以跳过啦。否则的话就不能跳过。要进行恢复
2. 跳过已经刷新到磁盘的页面
怎么恢复
崩溃恢复的过程
redo日志(下)
因为数据库要保证原子性，怎么才能提供回滚功能，让这个事务看起来什么都没做呢?
它是用来干什么的
当插入了一条信息，至少需要把这条记录的主键值记录下来，之后回滚的时候就可以根据这个主键值把相应记录删掉
当删除了一条记录，则至少要把这条记录中的内容都记录下来，回滚的时候进行插入
当更新了一条记录，则至少要把旧值记录下来，回滚的时候进行恢复旧值
记录回滚信息
主要是把这条记录的主键信息记上
INSERT操作对应的undo日志
本质是一个指针，指向记录对应的undo日志
roll_pointer隐藏列的作用
DELETE操作对应的undo日志
更新记录时，对于被更新的每个列来说，如果更新后的列和更新前的列占用的存储空间都一样大
就地更新
更新记录时，如果有任何一个被更新的列更新前和更新后占用的存储空间不一致
先删除掉旧记录(用户线程同步做delete mark与purge操作)，再插入新记录
不更新主键的情况产生1条UNDO日志，对应TRX_UNDO_UPD_EXIST_REC
将旧记录进行font color=\"#c41230\
根据更新后各列的值创建一条新记录，并将其插入到聚簇索引中
分两步操作
产生2条UNDO日志分别对应DELETE的UNDO日志（在对记录进行delete mark之前） 和 INSERT的UNDO日志 (在插入新记录时)
更新主键的情况
UPDATE操作对应的undo日志
生成TRX_UNDO_UPD_EXIST_REC类型的undo日志
undo日志（上）
存放UNDO日志的 FIL_PAGE_UNDO_LOG页面
每个的事务链表要分开
普通表和临时表的链表要分开（原因：临时表不需要记录REDO日志）
不同类型的链表要分开
UNDO页面链表
为每个UNDO页面链表生成一个段UNDO LOG Segment Header
存储一组（同一事务同一链表）信息的UNDO LOG HEADER
重用UNDO链表
有1024个slot，对应1024个链表
存储多个链表的first undo page的回滚段ROLLBACK Segment Header（表空间，页号）
在5号页面存放128个ROLLBACK Segment Header的地址提高支持UNDO链表的数量（128组*每组1024个插槽）
多个回滚段存放多个ROLLBACK Segment Header信息
第0号、第33～127号回滚段属于一类
第1～32号回滚段属于一类（存放临时表）
回滚段的分类
按着UNDO页面链表的存储结构来就好啦。还要加上重用链表的相关优化（即分配slot前先查看有没有缓存的链表）
为事务分配Undo页面链表详细过程
undo日志(下)
1. 为了让回收的时候更方便。2. 还有插入日志的时候避免竞争，提高插入速度
区别在于前者需要记录REDO日志，后者不需要
如果一个事务修改了另一个未提交事务修改过的数据
脏写
如果一个事务读取到了另一个未提交事务修改过程的数据
脏读
如果一个事务能读到了另一个已经提交的事务修改过的数据，并且其他事务每对数据进行一次修改并提交后，该事务都能查询得出最新的值。
不可重复度
如果一个事务先根据某些条件查询出一些记录，之后另一个事务又向表中插入符合这些条件的记录。则原先的事务再次按照该条件查询时，能把另一个事务插入的记录也读出来。
幻读
事务并发执行遇见的问题
读未提交
READ UNCOMMITED
读已提交
READ COMMITED
可重复读
REPETABLE READ
可串行化
SERIALIZABLE
SQL标准中的隔离级别
类似于git工作流
通过生成一个ReadView，然后通过ReadView找到符合条件的记录版本（历史版本是由undo日志构建的），其实就像是在生成ReadView的那个时刻做了一次时间静止（就像用相机拍了一个快照），查询语句只能读到在生成ReadView之前已提交事务所做的更改，在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。
Multi-Version Concurrency Control (多版本并发控制)
读取记录的最新的版本即可
进行加锁。读写，写写操作排队访问
可见性问题
表示在生成ReadView时当前系统中活跃的读写事务的事务id列表
m_ids
表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值
min_trx_id
表示生成ReadView时系统中应该分配给下一事务的id
max_trx_id
表示生成该ReadView的事务的事务id
creator_trx_id
4个重要的概念
如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。
可见性的推断
控制可见性的ReadView
判断版本链中哪个版本是当前事务可见的
所以会有不可重复读现象
每次读取数据前都生成一个ReadView
所以不会有不可重复读现象
在第一次读取数据时生成一个ReadView
MVCC的原理
insert undo在事务提交之后可以被释放掉了； 而update undo由于还需要支持MVVC，不能立即删除掉
为了支持MVVC，对于delete mark操作来说，仅仅是在记录上打了一个删除标记，并没有真正将他们删除掉。
随着系统的运行，在确定系统中最早产生的那个ReadView的事务不会再访问某些update undo日志以及被打了删除标记的记录后，有一个后台运行的purge线程会把它们真正的删除掉。
关于purge（清除）
事务隔离级别与MVCC
事务
0 条评论
回复 删除
下一页
