【MySQL】深入浅出InnoDB存储引擎（一）

最近看了mysql的一个优化课程，做点笔记。

undo 文件和redo log文件 、bin log 文件
首先，我们看一下一条update sql在mysql中是如何执行的。

update user set name='a' where id=1

当后端发起更新请求的时候，mysql服务器，有自己的数据库线程池专门处理来自各个地方的sql请求，然后线程收到sql请求后，调用myql的SQL接口，接着调用sql解析器、查询优化器，执行器，存储引擎，一系列操作后过程后，磁盘文件更新。

1、mysql redo日志的三种刷盘策略

redo文件刷入磁盘的策略，由innodb_flush_log_at_trx_commit这个参数来控制。

1.1 当等于0的时候

  表示redo 内容，当提交事务的时候，mysql并没有把innodb缓存里的redo内容，写入磁盘，这些redo内容仅仅存在innodb 缓存里。这个时候如果系统宕机，那这些redo 数据是会丢失的。也就是就算你提交了事务，这次变更没有得到有效的保存，发生了数据丢失故障。

1.2 当等于1的时候

   表示redo内容，当提交事务的时候，mysql一定会把存在innodb 缓存里的redo 内容刷入磁盘，实现物理存储。这是最可靠的，mysql可以保证你提交事务成功的同时，他一定把redo 缓存写入磁盘。宕机恢复后，mysql会从redo 里恢复没有执行的命令，更新数据文件。

1.3 当等于2的时候

   表示redo内容，当提交事务的时候，mysql只是把innodb 缓存里的redo 内容，刷到系统os cache里，从应用缓存，到了系统缓存。然后经过x秒（默认是1秒），系统会把这个os cache 写入磁盘。假如1秒内，系统宕机了，os cache内容没来得及保存，这也会导致redo内容丢失。造成了数据故障。事务提交了，但是数据没更新。

所以，对数据库这种严格的系统来说，这个参数最好设置为1，保证事务提交之后，数据绝对不能丢失。

2、binlog是什么。和redo log 的区别？以及它的写入磁盘策略？

   binlog，是msyql server的日志文件，redo log是存储引擎innodb的日志文件，是innodb独有的东西。

binlog记录的内容，大概是，对xx表id=xx的数据，做了更新操作，更新后的值为xx。“这个和我们日常开发应用，打的日志类似。
redo log，是那种物理性存储日志，内容是在什么数据页，什么位置做了个修改。内容注重的是磁盘位置，比较详细。
提交事务的时候，innodb会把自己缓存里的redo log刷入磁盘，而mysql server也会把自己的binlog 写入磁盘。binlog 写入完成后，还得在redo log末尾追加一个commit标识，标识redo log，binlog都已经写入磁盘完成。这样的好处就是，能完全保证两者都已经写入磁盘，不会出现对不上的问题。这个思想，应用到消费kafka消息，保证消息消费后，offerset也能同步被保存。比如消费的消息要存入mysql，那么把offerset也一起写入mysql，在表里增加一列存放这个offerset，就非常完美了。这个思想是一样的。
binlog 写磁盘的策略有2中，由sync_binlog这个参数控制。
等于0的时候，就是仅刷入os cache 系统缓存，没有真正写入磁盘。
等于1的时候，就是提交事务的时候，强制将binlog 写入磁盘。

提交事务后，binlog，redo log都写完啦。但是innodb存储引擎里的buffer pool的数据，没有被更新到磁盘的文件表里。这时候，存储引擎也有自己的IO线程，专门负责将buffer pool里的缓存更新到磁盘文件里。这是个定时线程。