MySQLInnoDB事务日志详解：RedoLog与UndoLog

### Redo Log

InnoDB事务日志主要包含Redo Log（重做日志）和Undo Log（回滚日志）。Redo Log用于记录数据页的物理修改，确保数据在系统崩溃后能够恢复到最近的提交点；而Undo Log则用于提供回滚操作和支持多版本并发控制（MVCC）。

#### Redo Log的基本概念

- **物理日志**：Redo Log记录的是数据页的物理变化，而非具体的数据行变化。
- **恢复机制**：Redo Log主要用于恢复已提交的事务，确保数据的一致性和完整性。
- **日志结构**：Redo Log包括内存中的日志缓冲区（redo log buffer）和磁盘上的重做日志文件（redo log file）。内存中的日志缓冲区是易失性的，而磁盘上的日志文件是持久化的。

#### 写入机制

- **force log at commit**：InnoDB通过这一机制确保事务的持久性。在事务提交时，必须将事务的所有日志写入磁盘上的Redo Log文件和Undo Log文件。
- **fsync操作**：每次将日志缓冲区中的日志写入日志文件时，都会调用操作系统的fsync操作，确保日志被写入磁盘。
- **innodb_flush_log_at_trx_commit**：该变量控制事务提交时日志的写入策略，有三种值：0、1、2，默认为1。设置为1时，每次提交都会将日志写入磁盘，保证数据安全；设置为0时，每秒写入一次，可能导致数据丢失；设置为2时，每次提交写入操作系统缓冲区，每秒同步到磁盘。

### 日志块

- **存储单位**：Redo Log以512字节的块（redo log block）为单位存储。
- **日志块结构**：每个日志块由日志块头（12字节）、日志块尾（8字节）和日志主体（492字节）组成。
- **日志格式**：Redo Log记录的是数据页的变化，每个日志块的主体部分包括日志类型（1字节）、表空间ID（压缩后可能小于4字节）、页偏移量（压缩后）和日志数据。

### 刷盘规则

- **脏日志**：内存中未写入磁盘的日志称为脏日志。
- **刷盘时机**：
- 事务提交时。
- 每秒自动刷盘。
- 当日志缓冲区使用超过一半时。
- 发生检查点（checkpoint）时。

### Checkpoint

- **脏数据**：内存中未写入磁盘的数据称为脏数据。
- **触发条件**：
- 系统内存不足。
- 日志文件达到最大值。
- 系统定期触发。

### Binlog与Redo Log

- **Binlog**：MySQL Server层实现的日志，记录的是SQL语句的逻辑变化。
- **Redo Log**：InnoDB引擎特有的物理日志，记录的是数据页的物理变化。
- **区别**：
- **格式**：Redo Log是物理日志，Binlog是逻辑日志。
- **用途**：Redo Log主要用于崩溃恢复，Binlog主要用于数据归档和主从复制。
- **写入方式**：Redo Log是循环写入的，Binlog是追加写入的。

### Undo Log

- **作用**：提供回滚和多版本并发控制（MVCC）。
- **逻辑日志**：记录的是逻辑变化，如删除操作记录为插入，更新操作记录为相反的更新。
- **存储管理**：InnoDB使用回滚段（rollback segment）管理Undo Log，每个回滚段包含1024个Undo Log段。
- **删除机制**：事务提交时，Undo Log不会立即删除，而是放入删除列表中，由Purge线程异步处理。

### 慢查询日志

- **功能**：记录响应时间超过阈值的SQL语句，帮助优化查询性能。
- **配置**：通过`long_query_time`参数设置阈值，默认为10秒。
- **启用**：默认情况下，慢查询日志是关闭的，需要手动启用。启用后，日志可以写入文件或数据库表。