undo log
undo log会记录修改数据之前的信息，事务中的原子性就是通过undo log来实现的。所以，有undo log可以帮我们找到「版本」的数据
redo log
持久性由redo log 日志来保证，当我们要修改数据时，MySQL是先把这条记录所在的「页」找到，然后把该页加载到内存中，将对应记录进行修改。
候选者：为了防止内存修改完了，MySQL就挂掉了（如果内存改完，直接挂掉，那这次的修改相当于就丢失了）。
候选者：MySQL引入了redo log，内存写完了，然后会写一份redo log，这份redo log记载着这次在某个页上做了什么修改。
作者：Java3y
链接：juejin.cn/post/701648…
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
bin log
binlog是归档日志，属于MySQL Server层的日志。可以实现主从复制和数据恢复两个作用。当需要恢复数据时，可以取出某个时间范围内的binlog进行重放恢复即可。
binlog 日志有三种格式，分别是statement，row和mixed。
如果是statement格式，binlog记录的是SQL的原文，他可能会导致主库不一致(主库和从库选的索引不一样时)。我们来分析一下。假设主库执行删除这个SQL（其中a和create_time都有索引）如下：
delete from t where a > '666' and create_time<'2022-03-01' limit 1;
复制代码
我们知道，数据选择了a索引和选择create_time索引，最后limit 1出来的数据一般是不一样的。所以就会存在这种情况：在binlog = statement格式时，主库在执行这条SQL时，使用的是索引a，而从库在执行这条SQL时，使用了索引create_time。最后主从数据不一致了。
如何解决这个问题呢？
可以把binlog格式修改为row。row格式的binlog日志，记录的不是SQL原文，而是两个event:Table_map 和 Delete_rows。Table_map event说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。row格式的binlog记录的就是要删除的主键ID信息，因此不会出现主从不一致的问题。
但是如果SQL删除10万行数据，使用row格式就会很占空间的，10万条数据都在binlog里面，写binlog的时候也很耗IO。但是statement格式的binlog可能会导致数据不一致，因此设计MySQL的大叔想了一个折中的方案，mixed格式的binlog。所谓的mixed格式其实就是row和statement格式混合使用，当MySQL判断可能数据不一致时，就用row格式，否则使用就用statement格式。
