1. MySQL常见的日志
1. 错误日志：对MySQL的启动、运行、关闭过程进行记录。不仅记录了错误信息，还记录了一些警告信息或者正确信息
2. 满查询日志：记录超过设定阈值的慢SQL
3. 查询日志：记录所有对数据库的请求信息，无论这些请求是否得到了正确执行
4. 二进制日志：记录了对数据库执行更改的所有操作。主要用途是主从复制，数据恢复
5. 重做日志：Innodb引擎层，记录了事务执行过程中对每个数据页的修改信息。主要用途是实现事务中的一致性
2. 重做日志和二进制日志的区别
1. 实现层级不同。重做日志是Innodb引擎独有的，二进制日志是MySQL Server层写入的
2. 存储内容不同。二进制日志存储的是逻辑日志，重做日志存储的是物理日志
3. 写入方式不同。重做日志是循环写入，文件总大小是固定。二进制日志可以追加写入。
3. 二进制日志缓冲区
MySQL为每个会话分配了一个二进制日志缓冲区，其大小有binlog_Cache_size控制，默认32K。当使用支持事务的存储引擎时，在一个事务中，对数据的修改操作会写入到缓冲区，在事务提交前，将缓冲区的内容写入到系统缓存。至于何时写入到二进制文件，是由sync_binlog控制的。sync_binlog = [N] 表示每写缓冲多少次就同步到硬盘。默认为0即有操作系统决定何时同步，设置为1，则每次提交都会写入硬盘。
4. 二进制日志和数据库一致性问题
当引擎支持事务时，为了保证高可用，sync_binlog需要设置为1。但是依然会有数据不一致的问题，比如事务提交会写入二进制文件，但是此时发生宕机，事务没有成功提交，那么二进制日志是无法回滚的。为了解决这个问题，MySQL提供了额外的配置项innodb_support_xa，设置为1来解决。了解分布式事务的应该知道XA协议，即两阶段提交协议。
5.什么是数据库二阶段提交
1. 准备阶段：刷新重做日志缓存到重做日志文件
2. 提交阶段：刷新二进制文件缓存到二进制日志文件，将重做日志打上commit标识
6.情况分析
1. 在重做日志文件写入前奔溃
2. 在重做日志写入后，二进制文件写入时崩溃
3. 在二进制文件写入后，commit标识设置前崩溃
4. 在commit标识设置后崩溃
对于情况1，重做日志还没写相当于这个事物没有执行
对于情况2，数据库检查二进制文件格式发现不完整，回滚事物，这条记录在载入binlog时也因为异常而不会生效
对于情况3，数据库检查二进制文件格式发现完整，提交事物
对于情况4，发现重做日志已有commit标识，提交事物
上述4种情况下，二进制文件和数据库都是一致的
