1.redolog
1.为什么要有redolog
更新的时候,直接更新磁盘数据效率低(随机写),所以先写入redo-log,更新内存数据,直接返回就行了.
2.那磁盘上的数据什么时候会刷呢?
首先redo log不是一个无限大的文件,有固定大小,所以当redo log满的时候,肯定会刷新磁盘,更新数据.这时候刷已经晚了,用户插入数据已经开始阻塞了.
第二个是,mysql线程会定期刷redo log到磁盘.
3.用处
用于崩溃恢复.crash safe
redolog,两阶段,redolog-prepare , binlog,redolog-commit
崩溃恢复的流程:
1.使用磁盘数据恢复后,依次读取redo log.
2.如果redo log记录的事务,有完整的 prepare和commit,那么要提交本次事务
3.如果redo log记录的事务,有prepare和binlog,那么要提交.如果不提交,我用这个binlog去同步或者恢复到某一个时间点,就会多一条数据
4.如果redo log记录的事务,只有prepare,那么需要回滚,因为如果我用这个binlog去同步或者恢复到某一个时间点,就会少一条数据
2. binlog
更新数据的sql.用于主从复制.以及数据恢复到某个时间点.
可以看出,两步提交,是为了在崩溃恢复和主从复制时,两者的数据达成一致!
问题:
1.可不可以只有redolog,没有binlog.
理论上可以,只有redolog,可以实现crash-safe.
但是binlog可以实现归档,第二个是有系统可以去消费binlog
binlog什么时候写. 事务执行的时候,会把binlog写入cache,当提交事务的时候,会写入磁盘(注意,其实是写入到pageCache,可以设置多少个事务调用fsync刷盘,如果设置为0,那么每次都刷盘,如果设置为n,那么如果异常重启有可能丢失n条日志)
3.changeBuffer
当一个更新过来的时候,如果数据在内存中,那么直接更新就行了,
但是如果不在内存中,那么就需要去磁盘读取,这岂不是很慢?
所以.为了避免随机读,引入了changeBuffer.在更新时,如果是普通索引,会直接把更新语句记录在changeBuffer,然后再次用到此页数据时,读入内存,同时merge.
4.undo log
什么是undo log,其实是逻辑上的日志.每一行数据都会有一个列 transactionId. 每个事务开始时,都会有一个事务id.mvcc机制就是基于transactionID
当一个事务开始时,会记录下当时的活跃事务列表.
查询一条数据时,如果此数据的事务id>当前事务id,那么说明当前事务执行的时候,有新的事务对数据进行了更新.那么这个值你应该看不到的.
那么此时,需要往前找,例如一条数据 tid=10,value=a--->tid=12,value=b--->tid=17,value=c,如果当前事务tid=13,那么应该看到的数据是b
那索引上是否也会包含事务id呢? 会的.
例如索引树上有一条数据 tid=10,value=a, tid=15,删除该数据.
当tid=11,查询时,就会看到这个数据
当tid=17,查询时,就看不到.
那这个数据啥时候回删除掉呢?当然是没有事务可以看到这条数据.例如当前活跃事务中,最小的是18.那么a这条数据就可以删除了.
在实际存储中,每行数据都存储着3个字段. 隐藏id,事务id,回滚指针
2.更新数据
3.更新数据