MySQL 的日志系统简单介绍

前提知识

一条查询语句的执行过程是先经过连接器，（查询缓存），分析器，优化器（生成执行计划，选择最优索引），执行器（操作引擎提供的接口），最后到达存储引擎（InnoDB等）。

如果是一个表上有数据的更新，这个表的所有查询缓存就是失效，所以一般不会太依赖查询缓存。

redo log介绍

redolog 属于引擎层操作。

如果Mysql每一次更新都会写盘的话，肯定需要先查找，然后更新，查找和IO的成本都很高。

所以Mysql本身也会有一个缓存。

MYSQL是先写日志，再写磁盘，也叫WAL (Write Ahead Logging)，对于InnoDB来说，就是先把记录写到redo log，更新内存（到这里这条SQL就算操作完成了），随后InnoDB会在适当的时候吧操作记录更新到磁盘。

并且这个redo log 固定大小（可配置）的环形区域，如果刷盘速度过慢，导致整块内存已经快满了，说明需要新刷盘，再 接受新的请求写入了。

binlog 介绍

binlog 属于Server层，也叫归档日志。

binlog 是没有crash-safe 能力。

另外Bin log 是逻辑日志（动作，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有），

redo log 是物理日志（记录这个页 做了什么改动）

Binlog 是一个可以顺序的不停追加，但是redo log是内存的循环空间

update语句的执行流程

update table set a=2 where id =2;

执行器在引擎按照条件查找对应的行;

执行器拿到行数据后，执行对应的修改逻辑；

调引擎的接口把这条数据更新

引擎会先把新的数据保存到内存里，同时记录操作记录 redo log （prepare），然后告诉执行器执行完成了，随时可以提交

执行器会生成binlog，并写入磁盘（顺序写盘，速度较快）

写盘完成后会调引擎的提交事务接口，redo log 状态修改为 commit 已提交。执行完成。

日志的持久化配置问题

由于redolog 有crash safe 的能力，所以可以保证不会丢数据。

有一个配置项 innodb_flush_log_at_trx_commit 配置成1 代表每次实物店额redo log都会直接持久化的磁盘。这样可以保证MySQL异常重启之后不丢数据。

另外如果 sync_binlog 配置为1 ，代表每次事务的binlog 会持久化到磁盘，这样可以保证MySQL异常重启后binlog 不丢失