InnoDB是一个带有ACID事务支持的存储引擎，其中redo log和undo log是其实现原子性、一致性、隔离性和持久性（ACID）的重要机制。
Redo Log（重做日志）
Redo log主要用于实现事务的持久性。它记录了后续可以用来恢复数据的“重做”操作。如果数据库崩溃，可以使用redo log记录复现完整的数据修改过程。Redo日志关注的是数据页的物理修改，并且这些记录是在事务提交之前写入的。通常，这些日志按照先后顺序被连续地写入到日志文件，这减少了IO操作的随机性，有助于提高性能。
Redo日志文件通常作为一个循环使用的日志组维护，一个文件满了之后就会滚动到下一个，形成一个循环。一旦数据被安全地写入到磁盘上的表里，相关的redo日志就可以被重用。
Undo Log（撤销日志）
Undo log主要用于实现事务的原子性和一致性。它记录了可以用来撤销每一个操作的信息。如果一个事务部分完成就失败或者被中止了，数据库将利用undo log来回滚事务对数据的修改，确保数据库能够返回到事务开始之前的一致状态。
Undo日志还用于实现事务的隔离性。在可重复读(REPEATABLE READ)和读已提交(READ COMMITTED)隔离级别中，读取操作需要访问事务开始之前的数据版本。如果在事务中修改了数据，这些旧的数据版本可以通过undo记录来访问。Undo日志存储在undo表空间中，不断积累的undo日志会定期清理，例如当所有需要该记录的事务都完成的时候。
Redo和Undo工作流
在一个数据库事务的生命周期中，redo和undo log通常这样工作：
当事务开始时，它可能会读取一些数据并更新它们，这些更新实际上写入了内存中的数据页（并不直接写入磁盘）。
数据库将这些修改操作记录到undo log中，这样如果事务需要回滚，就可以恢复原先的数据。
同时，将修改操作也记录到redo log中。如果数据库系统崩溃，事务的修改可以通过redo操作重新应用。
当事务提交时，数据库确保所有的redo log都已经写入了磁盘。这种写前日志（write-ahead logging）的策略保证了即使数据库在此时崩溃，所有提交的事务的修改都不会丢失。
提交事务后，数据库还会继续将内存中更改过的数据页刷新到磁盘中，这个过程可以异步进行，不需要立即完成，因为重做日志已经安全写入。
清理阶段，事务完成后，如果undo log不再需要，它们将被删除。
重要的是要理解，redo log记录的是如何重做一个操作，而undo log记录的是如何撤销一个操作。Redo log在事务提交时写入磁盘保证了持久性，而undo log让事务可以回滚到任何之前的状态来保证原子性和一致性。两者组合保障了事务的完整性和数据库的稳定性。
Bin Log
binlog有三种日志格式
1. STATEMENT（基于语句的复制Statement-Based Replication, SBR）: 每个数据库更改（如INSERT, UPDATE, DELETE）都会以SQL语句的形式记录在二进制日志文件中。
2. ROW（基于行的复制Row-Based Replication, RBR）: 而不是记录SQL语句，基于行的格式会记录更改了哪些行以及这些行如何改变。它记录了每个更改的具体行和列的新值。
3. MIXED（混合格式Mixed-Based Replication, MBR）: MySQL会智能地选择使用基于语句或基于行的复制格式。对于大多数语句，它使用基于语句的格式，因为这通常更有效（占用更少的空间并且在某些情况下复制更快）。然而，对于那些可能导致数据不一致的语句（例如，含有`NOW()`, RAND(), 或者用户定义的函数），它会使用基于行的格式。
`MIXED` 模式基本上是一个折中方案，它试图平衡基于语句的复制的效率和基于行的复制的一致性。在某些场景下，基于语句的复制可能会导致主从服务器之间的数据不一致，因为某些非确定性的函数可能在主服务器和从服务器上产生不同的结果。在这些情况下，使用 MIXED`模式可以确保复制的正确性，同时保持尽可能高的效率。
要在MySQL中设置复制格式，可以在配置文件 my.cnf（或 my.ini）中或通过命令行设置 binlog_format变量，
例如
[mysqld]
binlog_format=MIXED或者动态设置：
SET GLOBAL binlog_format = MIXED;务必记得，改变二进制日志格式会影响所有随后的数据更改事件，所以在生产系统中修改它之前需要仔细考虑，并保证主从数据库设置的一致性，避免复制错误。
