浅谈mysql的日志

1.慢查询日志

        使用 show variables  like '%slow_query_log%'这句进行查看慢查询日志是否开启1表示开启，0表示关闭，slow_query_log_file这个表示慢查询日志在文件中的那个位置

        使用show variables like 'long_query_time%';这句查看执行了多少秒算慢sql 使用set global long_query_time=4;进行修改

2.binlog归档日志

        binlog日志只会记录对表进行修改或者对表结构产生了修改操作的二进制文件，例如select,show这些操作就不会记录进去，binlog是追加写入，所以它写道一定大小后就会再创建另外一个日志文件，例如mysqi-bin.01然后这个序号是递增的。它有三种格式第一种是STATEMENT，它会直接记录sql语句，但如果进行恢复的时候会产生歧义例如使用了now()这些函数的语句，第二种是ROW，它会记录这条修改语句前后数据的值，这样准确性很强，但可读性比较差需要借助mysqlbinlog解析，然后如果修改字段过长的话会生成较多的binlog文件，如果是修改表结构的语句那么会产生较多的io交互和日志量，第三种是MIXED，这种就是直接集成前面两种，会产生歧义的语句用ROW，不会产生歧义的会用STATEMENT，归档日志主要用于数据恢复和主从复制

        当你数据误删的时候就可以找到最近一次全量备份的binlog文件然后开始重放binlog进行全量恢复数据，binlog默认不开启

3.redo重做日志

        如果mysql突然宕机或者挂了那么就需要用redo日志来进行数据恢复，它是innerDB特有的日志，它由两部分组成redo log buffer和redo log file。

        在mysql中数据是以页为单位，当查询一条数据的时候那么会从硬盘中拿取一页的数据放入Buffer pool中，然后查询会先查询Buffer Pool，修改也是，然后把这些修改的记录放在redo log buffer中最后进行刷盘存入redo log file中

        不直接持久化的原因是，mysql数据以页为单位，如果一次修改就持久化那么刷新的就是整页的数据，造成io浪费，但一个事务基本会涉及多个操作，那么先进入缓存一次性刷新会比多次要好一些。

4.undo log回滚日志

        当我们进行持久化后如果想回滚那么就要用到undo log,此日志在浅谈机制问题中有写

5.两段式提交

        在mysql InnerDB引擎中，如果开启了binlog日志，那么binlog日志和redo日志就可以配合实现两段式提交，redo先进行prepare阶段准备提交。然后binlog进行提交，最后redo进行commit,为什么要两段式提交，因为如果redo prepare成功了而binlog 提交阶段失败了，那么binlog没有修改的这条记录那么就会回滚到最原始的数据，而redo文件中有记录，那么重启的时候就会回滚到这个修改的记录的数据造成数据不一致，例如update test set a = 1 where a = 0; redo成功后就会记录这条语句，binlog回滚会恢复成0，而redo会恢复成1造成数据不一致，而如果是两段式提交，那么mysql进行数据恢复的时候发现redo还处于prepare状态就不会回滚。

        而如果redo处于commit状态出错，那么由于binlog中已经有这个事务的id所以不会回滚事务而是提交事务