MySQL崩溃保险箱：探秘Redo/Undo日志确保数据库安全无忧！

《MySQL崩溃保险箱：探秘Redo/Undo日志确保数据库安全无忧！》

MySQL 中的日志主要有三种类型：二进制日志（Binary Log），重做日志（Redo Log），和撤销日志（Undo Log）。这三种日志在 MySQL 中扮演着不同的角色，以确保数据库的 ACID 特性（原子性、一致性、隔离性、持久性）。

一、MySQL三大日志

1. 二进制日志（Binary Log）

作用：

• 记录所有对数据的修改操作，包括插入、更新、删除等。
• 用于数据复制（replication）、点对点复制（binary log based replication）、数据备份和恢复。

特点：

• 以二进制形式存储，不可读。
• 可以包含多种事件类型，如表映射、写入行、更新行、删除行等。

查看和导出：

# 查看二进制日志内容
mysqlbinlog binlog-file

# 将二进制日志转换为 SQL 语句
mysqlbinlog binlog-file | mysql -u root -p

2. 重做日志（Redo Log）

作用：

• 记录数据页的物理修改操作，确保事务的持久性。
• 在事务提交前，将修改操作写入重做日志，以防数据库崩溃导致数据丢失。

特点：

• 存储在磁盘上，通常是两个文件：ib_logfile0 和 ib_logfile1。
• 循环写入，保证事务的顺序性和原子性。

调整配置：

# 在 MySQL 配置文件中修改重做日志文件大小
[mysqld]
innodb_log_file_size=100M

3. 撤销日志（Undo Log）

作用：

• 记录事务对数据所做的修改的逆操作。
• 用于事务回滚和 MVCC（多版本并发控制）。

特点：

• 存储在表空间中，通常是 ibdata1 文件。
• 事务提交后，撤销日志用于回滚事务或提供一致性读取。

查看撤销日志：

SHOW ENGINE INNODB STATUS;

这三种日志共同工作，确保了 MySQL 数据库的稳定性和一致性。在数据库的正常运行中，这些日志是透明的，但在需要进行数据复制、备份和恢复时，它们发挥着关键的作用。

二、事务日志

2.1、作用

MySQL 的 redo log 和 undo log 是两个重要的日志文件，它们用于确保数据库的持久性和可恢复性。

redo log 的作用

redo log 是用来记录数据库事务的更改的一种日志。记录的是数据库事务的物理修改。它记录了事务对数据页的实际更改操作，通常是新数据的修改。这样，在数据库崩溃或重启后，通过重做日志可以重新应用这些修改，确保事务的持久性。

当用户执行 DML 或 DDL 语句时，MySQL 会将这些更改记录到 redo log 中。当 MySQL 服务器崩溃时，可以使用 redo log 将数据库恢复到事务开始时的状态。

redo log 是 MySQL 数据库持久性的关键。如果没有 redo log，在 MySQL 服务器崩溃后，数据库可能会丢失所有更改。

undo log 的作用

undo log 是用来记录数据库事务的回滚信息的一种日志。它用于在用户撤销或回滚事务时恢复数据。

当用户执行 DML 语句时，MySQL 会将这些更改记录到 redo log 中，并将旧数据记录到 undo log 中。当用户撤销或回滚事务时，可以使用 undo log 将数据库恢复到事务开始前的状态。

undo log 是 MySQL 数据库可恢复性的关键。如果没有 undo log，用户无法撤销或回滚事务。

redo log 和 undo log 的区别

redo log 和 undo log 的主要区别如下：

属性	redo log	undo log
作用	记录数据库事务的更改，用于在 MySQL 服务器崩溃后恢复数据	记录数据库事务的回滚信息，用于在用户撤销或回滚事务时恢复数据
记录的内容	数据库事务的更改	数据库事务的旧数据
使用场景	用于数据库恢复	用于数据库撤销和回滚

在实际使用中，MySQL 会同时使用 redo log 和 undo log。redo log 用于确保数据库的持久性，undo log 用于确保数据库的可恢复性。

• Redo Log 保证事务的 "提交后" 的修改能够被重新应用，以防止数据在持久化时的丢失，从而恢复数据库到提交后的状态。
• Undo Log 记录了事务对数据的 "修改前" 的逆操作，用于回滚事务或提供一致性读取，以确保数据库在事务执行期间的一致性。

MySQL通过 Redo Log 和 Undo Log 的协同工作，数据库能够在事务的执行、崩溃和恢复过程中保持一致性，并在需要时将数据恢复到事务开始时的状态。

2.2、开启

MySQL redo log 和 undo log 不需要手动开启。它们都是 MySQL 默认开启的。

redo log 是 MySQL 持久性的关键，因此它是默认开启的。如果 redo log 没有开启，则在 MySQL 服务器崩溃后，数据库可能会丢失所有更改。

undo log 是 MySQL 可恢复性的关键，因此它也是默认开启的。如果 undo log 没有开启，则用户无法撤销或回滚事务。

2.3、与binlog是否重复

• Redo Log 是为了确保事务的持久性，特别是在数据库崩溃的情况下。它记录的是 InnoDB 引擎对数据页的物理修改，是一种保障数据完整性和持久性的机制。
• Undo Log 是为了支持事务的回滚和提供一致性读取。在事务执行过程中，可能需要撤销某些操作，而 Undo Log 记录了这些逆操作。
• Binlog 则记录了对数据库的整体更改，而不仅仅是 InnoDB 存储引擎的更改。它对于数据库的复制、备份和恢复非常重要，同时也用于实现高可用性。

虽然它们都与事务和日志有关，但由于各自的设计目标和使用场景不同，它们是互补而不是冗余的。在数据库系统中，这些机制的共同作用确保了数据的一致性、持久性以及系统的可靠性。

三、InnoDB和MyISAM

MySQL 支持多种存储引擎，其中 InnoDB 和 MyISAM 是两个常用的引擎。它们在性能、事务支持、锁定机制等方面存在一些显著的区别。以下是 InnoDB 和 MyISAM 的一些主要区别：

1. 事务支持：

• InnoDB：

• • 提供事务支持，支持ACID（原子性、一致性、隔离性、持久性）特性。
  • 支持行级锁定，使得多个事务可以并发执行而不会导致数据不一致。

• MyISAM：

• • 不提供事务支持，不支持事务的回滚和提交。
  • 锁定级别较低，只支持表级锁定，容易导致并发写入冲突。

2. 锁定机制：

• InnoDB：

• • 使用行级锁定（row-level locking），允许多个事务同时对不同的行进行操作。
  • 对于读操作，InnoDB 不会进行锁定，允许多个事务并发执行。

• MyISAM：

• • 使用表级锁定（table-level locking），对整个表进行锁定。
  • 读操作和写操作都会对整个表进行锁定，可能导致性能瓶颈。

3. 并发性：

• InnoDB：

• • 更适合高并发环境，支持更多的并发写入操作。
  • 对于读操作，多个事务可以同时进行，不会相互阻塞。

• MyISAM：

• • 适合读密集型操作，对于写操作并发能力相对较弱。
  • 由于表级锁定，写操作可能会导致整个表的阻塞。

4. 事务安全表和崩溃恢复：

• InnoDB：

• • 提供事务安全表，支持崩溃恢复。
  • 通过事务日志（redo log）和撤销日志（undo log）实现崩溃恢复。

• MyISAM：

• • 不提供事务安全表，对于崩溃的恢复能力较差。
  • 不支持事务日志和撤销日志。

5. 索引：

• InnoDB：

• • 支持全文索引、空间索引等多种类型的索引。
  • 使用聚集索引，数据文件和索引文件是相互交织的。

• MyISAM：

• • 不支持全文索引和空间索引。
  • 使用非聚集索引，数据文件和索引文件是分开存储的。

6. 表的关联性：

• InnoDB：

• • 适合关联性较强的表，支持外键约束。
  • 外键约束确保了关联表之间的数据一致性。

• MyISAM：

• • 不支持外键约束，适合简单的查询和读操作。
  • 对于表之间关联性要求较高的应用，MyISAM 较为不适用。

以下是 InnoDB 和 MyISAM 存储引擎在一些关键方面的比较：