面试必备之MySQL数据库（binlog,redolog,undolog）

在MySQL数据库中，binlog、redo log和undo log是三种至关重要的日志，它们在数据库的事务处理、数据恢复和同步等方面发挥着关键作用。下面将详细解释这三种日志的作用、区别以及它们如何协同工作。

作用：binlog是MySQL的归档日志，记录了所有对数据库的数据、表结构、索引等变更的操作。它相当于数据库的“流水账”，用于归档、验证、恢复和同步数据。

记录内容：binlog记录了除了查询语句（select、show）之外的所有的DDL和DML语句。它以事件形式记录，不仅记录了操作的语句，还记录了语句执行的时间。binlog有三种记录格式：

• STATEMENT（5.6默认）：语句模式，原封不动地记录当前DML。
• ROW（5.7默认值）：记录数据行的变化，可读性较低，但足够严谨。
• MIXED：混合模式，结合了上述两种模式的优点。

应用场景：市面上一些成熟的工具和解决方案，如kafka-binlog和canal，通过解析binlog来实现数据同步与分析。

作用：redo log解决了MySQL在修改数据时，如果Buffer Pool中修改的数据还没有及时刷到磁盘，MySQL宕机重启会导致数据丢失的问题。它保证了事务的持久性。

工作原理：

• 当数据库修改数据时，会先将更新记录写到redo log中，再去修改Buffer Pool中的数据。
• 提交事务时，调用fsync把redo log刷入磁盘。
• 缓存中更新的数据文件何时刷入磁盘，由后台线程异步处理。

两阶段提交：MySQL数据更新的流程包括两个阶段：

1. 准备阶段：先将当前数据保存在undo log中，形成历史版本；然后将变更数据的记录写入redo log buffer，并通过顺序IO刷新到磁盘中的redo log中，将redo log的状态置为prepare。
2. 提交阶段：server层更新binlog日志文件，将数据变化写入binlog中；当binlog更新完成后，事务才算成功commit，并将commit状态写入redo log中；最后执行刷脏页操作。

写入策略：由innodb_flush_log_at_trx_commit参数决定：

• 1：每次事务提交时，将log buffer刷到文件系统中，并调用文件系统的“flush”操作将缓存刷新到磁盘上。
• 0：每隔一秒将log buffer刷到文件系统中，并调用文件系统的“flush”操作。
• 2：每次事务提交时，将log buffer刷到文件系统中，但不立即刷写到磁盘。

写入方式：redo log采用大小固定、循环写入的方式。当写满后，会重新从头开始循环写，类似一个环状。这样设计可以确保已刷到磁盘的数据页对应的redo log记录失效，新日志会覆盖这些失效的记录。

crash-safe能力：Innodb引擎具有crash-safe能力，即事务提交过程中任何阶段，MySQL宕机重启后都能保证事务的完整性。这种能力是通过redo log保证的，MySQL宕机重启后，系统将自动检查redo log，将修改还未写入磁盘的数据从redo log恢复到MySQL中。

作用：undo log属于引擎层（innodb）的日志，用于保证innodb事务机制中的原子性。事务提交成功由redo log保证数据持久性，而事务可以进行回滚则通过undo log来保证。

工作原理：在MySQL里，数据每次修改前，都会把修改之前的数据作为历史保存一份到undo log中。undo log记录了操作该数据的事务ID，可以通过事务ID对数据进行回滚。

回滚与前滚：

• 回滚：未提交的事务中，已刷盘的脏块需要被撤销。
• 前滚：已提交的事务中，未刷盘的数据需要从redo log中恢复出来并刷盘。

其他作用：undo log还为数据库实现了MVCC（多版本并发控制）的功能，这对于提高数据库的并发性能至关重要。

undo log记录内容：在数据修改前，将修改前的数据保存到undo log中，并记录操作该数据的事务ID。

综上所述，binlog、redo log和undo log在MySQL数据库中各自扮演着重要的角色。它们协同工作，确保了数据库的事务处理、数据恢复和同步等方面的可靠性和性能。在面试中，了解这三种日志的作用、区别以及它们的工作原理，将有助于你更好地理解和回答与MySQL数据库相关的问题。