MYSQL日志和事务原理

1)重做日志:在一个事务中会涉及到多个DML操作，修改的是在内存层面数据页中的数据，还没有及时的将修改之后的数据更新到磁盘中，真正的将更新后的数据写回到磁盘的时候才满足持久性，只是更新内存是不满足持久性的，如果只是更新内存就不叫做持久性，持久性是即使出现数据库的故障，宕机，也不能改变数据被修改的事实，如果出现内存中修改，结果以当即导致磁盘没有被修改，再一恢复，发现磁盘并没有修改，redolog是记录的是物理磁盘上面的页修改操作，比如说页号XXXX，偏移量XXX，写入了什么数据，主要是保证数据的可靠性，实打实物理磁盘的记录；

2)redo和undo都认为是一种数据恢复的操作

3)undolog其实实际上是一种逻辑上的操作，比如说我们写的SQL是逻辑上的操作，unlog记录的是逻辑相反的操作

1)为什么是以一定频率刷入磁盘?

因为写入磁盘本身就慢，刷盘中的页本身可能是不连续的，随机IO，性能不太好

2)假设事务里面有很多DML操作，这些DML操作都是操作的是内存中的数据，这个时候事务提交了，内存中的数据的修改都完成了，此时磁盘还没有被写入刷盘，逻辑上磁盘上的数据应该被修改了，但是此时commit操作MYSQL宕机了断电了，内存中的数据还没刷盘，如果这个时候没有redlog日志，再次重启内存中的数据没了，磁盘上的数据还是从前的，相当于事务没有执行，此时事务就不保证持久性；

3)能不能内存中修改数据，马上就修改磁盘数据，就以一定的频率刷入磁盘？

内存和磁盘是依靠页为单位来进行数据交互的，假设修改了一个字节，那么结果是要把整个页刷到磁盘中，数量大小的对比，效率太低，每进行一个字节的修改操作，都要刷盘嘛？

4)假设进行一个update不加条件，修改的数据在不同的页中，那么此时进行刷盘操作随机IO太麻烦，所以实时修改不太靠谱；

5)binlog日志，比如说在主从复制的环境下，主机负责写，从机负责读，那么如何来保证主从数据的一致性呢？就是依靠binlog二进制来实现的，比如说现在在主机中新增了一条记录，那么就在binLog中记录一下，从机从binlog中获取记录

 

redolog的刷盘策略:将redologbuffer中的数据放在redlogfile中

1)假设现在要进行更新操作，那么首先MYSQL会将要更新的数据的表加载到内存中 

2)修改完成之后，先在redologbuffer中做一个记录

3)然后再将内存层面中的redologbuffer中的数据写入到磁盘中的readlogfile；

4)最后进行刷盘；

真正的将文件系统cache中的数据刷入到redolog日志中，是由文件系统本身决定的

1)当设置成1的时候，随着事务的提交，redologbuffer中的数据马上就会刷到文件系统缓存中，然后这些数据会从文件系统缓存刷到redlog日志中

2)当设置成0的时候，事务提交，表示不会立即进行刷盘操作，而是等1s之后再进行刷盘操作，innodb会有一个后台线程，每隔1s就会将redo log buffer的内容写到文件系统缓存中然后再来执行刷盘操作

总结就是：0：延迟写，延迟刷，1：实时写，实时刷，2：实时写，延迟刷

只要修改数据，redo log buffer就会实时地做记录，参数影响的只是log buffer中的刷盘策略

undolog日志:

 

锁:

 

当在READ COMMITED情况下，ReadView中记录的是读已提交的数据(记录的是已提交事务

,此时Select操作只能读到已经提交的数据

 

比如说T1给表中的数据加了一个X锁，不管是T2的事务操作这一行数据加的是X锁还是S锁，实际上都是需要进行阻塞的

写的时候一定要加上排他锁