区分binlog和redologbinlog记录的是逻辑日志把二进制转化一下里面就是“UPDATE tb_student SET age16 WHERE name赵% ”这样的sql语句只记录增删改不记录查。redolog是物理日志记录的是磁盘上的数据发生了什么变化。binlog主要为了保证主从一致性。redolog主要让InnoDB存储引擎拥有了崩溃恢复能力。一、binlogMySQL的二进制日志binlog可以说是MySQL最重要的日志.binlog日志有两个最重要的使用场景。1mysql主从复制有两个数据库一个是主数据库另一个从数据库用来备份。主数据库把binlog传给从数据库就完成了主从复制。具体操作mysql replication在master端开启binlog,master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。2数据恢复通过mysqlbinlog工具来恢复数据。binlog日志包括两类文件1二进制日志索引文件(文件名后缀为.index)用于记录所有的二进制文件。2二进制日志文件(文件名后缀为.00000*)记录数据库所有的DDL和DML(除了数据查询语句select)语句事件。如何查看binlog日志文件常用有两种方式1、使用mysqlbinlog自带查看命令法注意1binlog是二进制文件普通文件查看器cat、more、vim等都无法打开必须使用自带的mysqlbinlog命令查看。2binlog日志与数据库文件在同目录中。3在Mysql5.5以下版本使用mysqlbinlog命令时如果报错就加上--no-defaults选项4使用mysqlbinlog命令查看binlog日志内容下面截取其中的一个片段分析分析解释server id 1:数据库主机的服务号end_log_pos 796 :sql结束时的pos节点thread_id11:线程号5也可根据时间点查看/home/software/mysql-5.1.72-linux-x86_64-glibc23/bin/mysqlbinlog --no-defaults mysql-bin.000720 --start-datetime2018-09-12 18:45:00 --stop-datetime2018-09-12:18:47:002. show binlog events上面这种办法读取出binlog日志的全文内容比较多不容易分辨查看到pos点信息下面介绍一种更为方便的查询命令mysql show binlog events [IN log_name] [FROM pos] [LIMIT [offset,] row_count];参数解释a、IN log_name:指定要查询的binlog文件名不指定就是第一个binlog文件b、FROM pos:指定从哪个pos起始点开始查起不指定就是从整个文件首个pos点开始算c、LIMIT【offset】偏移量(不指定就是0)d、row_count :查询总条数不指定就是所有行看这里mysql binlog详解_mysqlbinlog_油焖大虫下的博客-CSDN博客二、回滚日志 uodolog记录数据的历史版本。就俩作用单条命令/事务失败的时候回滚到单条命令/事务开始前的历史数据。PS单条命令也可能失败呀比如你执行一条update要更新10万行但是更新到50万行的时候断电了。MVCC终于搞明白回滚和前滚的区别了二者是反方向三、前滚/重做日志redolog数据先写到缓冲中再写入磁盘中但是如果事务已经提交了数据也写到了缓存中在提交到硬盘的过程中断电了。解决方法必须先写redolog再写数据库。binlog和redolog应该先写谁假设binglog主要用来实现主从同步。如果master先写binlog让数据A1然后写redolog的时候断电了断电重启后系统会自动redoredolog上没有A1的日志记录binlog和redolog上数据的修改不一致。那么maser重启redo的时候会丢失但是传给slave的binlog里存在A1这就造成了主从不一致。如果master先写redolog让数据A1然后写binlog的时候断电了。master重启后A1生效但是传给slave的binlog里不存在A1也造成了主从不一致。所以无论是先写binlog还是先写redolog都存在数据不一致的风险。相信你应该看出来了这俩应该要么一起写要么一起不写应该是原子性的才对。跟分布式事务的处理思路一样解决这种“没法原子性但硬要原子性”问题的方式就是标记中间状态。解决方法两阶段提交其实就是先写redolog再写binlog但是给redolog设置一个状态位写完redolog以后给他打个prepare标签标志着这是一个中间状态当binlog也写完了以后再把这个标签变成commit。使用两阶段提交后如果写入binlog时崩了因为MySQL严格来说是innodb引擎根据redo log日志恢复数据时发现redo log还处于prepare阶段并且没有对应binlog日志就会回滚该事务。看一个特殊情况如果崩的时候已经写入binlog了只不过还没来得及设置commit就崩了那会不会回滚事务呢不会回滚它会执行上图框住的逻辑虽然一看redo log打着prepare的标签但是如果能通过事务id找到对应的binlog日志就MySQL认为是完整的就会提交事务恢复数据。