读mysql45讲第二天

mysql中日志系统有在server层中的binlog日志（归档日志），还有InnoDB引擎层中的redolog日志（重做日志）；binlog中存储的是sql修改的逻辑日志。

show binary logs命令可以查看binlog日志文件，我在dbeaver中用这个命令查看显示是860和861

show binglog events in 'mysql-bin.000861’可以查看具体日志文件中的内容，但是我看了一会没看懂里面存的都是什么。

redolog存的是物理日志，也就是哪些行改变的值是什么。具体存的日志内容还是没太懂是什么，就记住了一个是物理日志一个是逻辑日志。

show variables like ‘innodb_log%’

可以查看redo日志相关的配置：

这里日志大小日志配置的是524288000，524288000/1024/1024差不多是500MB，一组是2个文件，那么这一组文件可以记录的大小就是1000MB左右；

图中write pos记录的是当前写入日志的地方，一边写一边往后移，当移到ib_logfile_3的末尾的时候，就会从ib_logfile_0重新开始；
check point是当前需要擦除的地方。每次执行更新语句的时候，InnoDB并不一定就立刻执行，而是先把记录存储在redolog日志里，然后更新内存，
这个时候就算是完成了，其实还没有更新到磁盘中。如果每次有更新语句来了，都去立刻写到磁盘里面，重复操作需要的成本也会很高，所以先记录在redolog日志里，
然后在数据库比较空闲的时候去执行，这样的执行效率就会比较高，有点类似IO中的缓冲区。

当有数据记录需要发生改变，InnoDB引擎会先把改变值写在redolog日志里，然后再更新到内存中，当数据库空闲的时候再去更新到磁盘，这个过程被称为WAL,
全称是Write-Ahead Loggin 关键点是先写日志 然后再更新到磁盘里。redolog日志使得在数据库发生异常重启的时候，之前提交的记录都不会丢失，这个能里成为Crash-Safe。

redo日志是固定大小的，是循环使用的，所以会不停的覆盖掉之前的日志，binlog是可以用追加的方式添加日志文件，所以不会覆盖之前的日志文件。
更新记录的大概流程：

1.执行器：将id=2的记录的num列加2
2.引擎层：引擎接口根据id=2找到那条记录，如果记录在内存中就直接返回，如果不在就从磁盘读取到内存再返回（这个地方我好奇记录不在内存就从磁盘中找，那什么情况会
让之前在内存中有的记录失效？内存要存的东西太多会把最早开始存在内存的东西给删掉？）
3.执行器：拿到这行值之后，给num+2然后返回给引擎层
4.引擎层：将num+2的值写到内存中，同时将这个值写入到redolog日志中，此时redolog处于prepare状态，然后告知执行器已经完成，可以提交事务。
5.执行器将这个更新操作生成binglog日志，然后写入到binglog的磁盘文件中
6.执行器调用引擎的提交事务接口进行提交事务
7.引擎接口接收到提交事务的请求将刚才的redolog日志的状态改成提交状态，更新完成。

可以看到写入redolog日志的操作有两个，第一次写入是prepare状态，第二次是commit状态。这就是两阶段提交。

两阶段提交可以防止数据库异常重启的时候，让redolog和binglog出现不一致的操作记录，也就是两阶段提交是为了让redolog和binglog尽量保证日志记录一致。

innodb_flush_log_at_trx_commit这个参数设置为1表示每次redolog记录日志的时候都会持久化到磁盘中，这样可以防止操作记录丢失；
sync_binlog参数为1表示每次binlog日志操作都会持久化到磁盘文件中。