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 -p2. 重做日志（Redo Log）
作用：
- 记录数据页的物理修改操作，确保事务的持久性。
- 在事务提交前，将修改操作写入重做日志，以防数据库崩溃导致数据丢失。
特点：
- 存储在磁盘上，通常是两个文件：
ib_logfile0和ib_logfile1。 - 循环写入，保证事务的顺序性和原子性。
调整配置：
# 在 MySQL 配置文件中修改重做日志文件大小
[mysqld]
innodb_log_file_size=100M3. 撤销日志（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 存储引擎在一些关键方面的比较：
