undolog,redolog,binlog分别是做什么的?

在数据库系统中（尤其是 MySQL），Undo log、Redo log 和 Binlog 是用于实现数据持久性和一致性的重要日志机制。

1. Undo Log（回滚日志）

功能：

• 用于事务回滚：记录事务开始前的状态，以便在事务失败或回滚时恢复到原来的数据状态。
• 实现多版本并发控制（MVCC）：在事务未提交时，其他事务可以通过读取 Undo Log 中的数据获取数据的历史版本。

工作原理：

1. 当事务对数据进行修改时，会先将修改前的数据记录到 Undo Log 中。
2. 如果事务发生错误或调用回滚操作（ROLLBACK），可以通过 Undo Log 将数据恢复到修改前的状态。
3. 如果事务提交了（COMMIT），Undo Log 对于回滚的作用就不再需要，但在 MVCC 的情况下可能仍然会被使用，直到没有事务需要访问这些版本数据时才会被清理。

示例：

-- 假设表有一条数据 UPDATE employees SET salary = 10000 WHERE id = 1;

• 事务未提交时：Undo Log 中保存原来的数据，比如 salary=8000。
• 事务回滚时：Undo Log 将 salary=8000 恢复到数据库。

2. Redo Log（重做日志）

功能：

• 保证数据的持久性：用于崩溃恢复，确保已提交事务的数据不会因为系统崩溃而丢失（WAL: Write-Ahead Logging）。
• Redo Log 是物理级别的日志，记录的是页级别的修改，而不是逻辑操作。

工作原理：

1. 事务提交前，数据库会先将 Redo Log 写入磁盘。
2. 数据变更先写入内存中的缓冲池（Buffer Pool），然后后台线程异步将缓冲池中的数据刷到磁盘。
3. 如果数据库崩溃，在重新启动时，可以通过 Redo Log 中的日志记录重做数据修改，确保数据的完整性。

关键点：

• Redo Log 是 InnoDB 存储引擎的一部分，与 MySQL Server 的 Binlog 不同。
• Redo Log 的写入顺序：
  1. 将变更写入 Redo Log 缓冲区。
  2. 事务提交时，将 Redo Log 持久化到磁盘。
  3. 将内存中的数据异步刷到磁盘。

示例：

• 如果系统崩溃了，但事务已提交：
  • Redo Log 会用来重做已提交的事务，确保提交的修改不会丢失。

3. Binlog（归档日志）

功能：

• 用于数据备份和主从复制：
  • 数据库的增量备份。
  • 主从复制（MySQL 主从复制是通过 Binlog 进行的）。
• 记录逻辑操作：Binlog 记录的是 SQL 语句（逻辑日志），而不是物理页的修改。

工作原理：

1. 当事务提交时，MySQL Server 层会将对应的 SQL 操作记录到 Binlog。
2. Binlog 记录的是追加写入（append-only）的文件，按顺序记录所有修改操作。
3. Binlog 被下游从库用于重放事务，从而实现主从数据同步。

关键点：

• Binlog 是 MySQL Server 层的日志，与存储引擎无关（如 InnoDB 或 MyISAM）。
• Binlog 支持三种格式：
  1. Statement（基于 SQL 语句）：记录 SQL 语句。
  2. Row（基于行的日志）：记录数据的具体变更。
  3. Mixed（混合格式）：结合 Statement 和 Row 的优点。

示例：

-- 示例事务 BEGIN; UPDATE employees SET salary = 12000 WHERE id = 1; COMMIT;

• Binlog 可能记录为：
  • Statement 格式：UPDATE employees SET salary = 12000 WHERE id = 1;
  • Row 格式：记录 id=1 的旧值和新值（行数据变化）。

对比 Undo Log、Redo Log 和 Binlog

总结与使用场景

1. Undo Log：保证事务的原子性（回滚操作）和一致性（MVCC 实现并发读取）。

   用于回滚未提交的事务或实现数据的历史版本。

2. Redo Log：保证事务的持久性（崩溃恢复）。

   用于系统崩溃后恢复已提交事务的数据，确保数据不会丢失。

3. Binlog：用于增量备份和主从复制。

   用于将数据变更记录下来，便于后续进行数据恢复、灾备或主从同步。

三者共同协作，确保 MySQL 数据库的高可靠性、事务一致性以及数据的备份与同步能力。