一 、上期回顾

上次小编讲了一条sql的执行流程，总结如下：

行级锁：对特定记录加锁，避免并发冲突。

数据修改：实际更新记录，记录修改到redo log。

事务控制（ACID）：事务提交或回滚，确保数据一致性和持久性。

然后小编也说了，InnoDB存储引擎里面不止做了这几件事，所以这期小编来聊聊InnoDB存储引擎做了哪些事情。

二 、innoDB

2.1 一条更新sql语句的执行流程图

2.2 buffer pool（innoDB）

Buffer Pool的定义

Buffer Pool 是一块内存区域，专门用于存储数据库的数据页和索引页，以便数据库在查询或更新数据时，能够直接从内存读取而不是从磁盘读取，极大地提高了查询性能。

Buffer Pool的作用

性能调优建议

另外 buffer pool既然是将物理磁盘的数据缓存起来，那么它的数据结构，内存不够时的淘汰策略等等，小编将新开一篇mysql innoDB的buffer pool单独讲解，有兴趣的同学记的关注后续文章。

2.3 undo log（innoDB）

Undo Log的定义

Undo Log 是用于记录数据在进行修改之前的状态的日志。当一个事务执行时，任何对数据的修改都会在修改前记录到Undo Log中。如果事务因为某些原因失败或被显式回滚，InnoDB会利用Undo Log将数据恢复到修改前的状态。

Undo Log的作用

如果一个事务在执行过程中出现错误或者用户显式执行ROLLBACK，InnoDB会利用Undo Log中的记录将数据恢复到事务开始前的状态，确保事务的原子性。

Undo Log与Redo Log的区别

2.4 redo log（innoDB）

Redo Log的定义

Redo Log 是一种物理日志，记录的是数据页的修改操作，而不是具体的数据内容。当一个事务对数据库中的数据进行修改时，InnoDB会先将这些修改操作记录到Redo Log中，然后再将这些操作实际写入到磁盘的数据文件中。

Redo Log的作用

在发生系统崩溃、宕机或硬件故障时，Redo Log能够用于重做未完成的事务，确保数据库在恢复时仍然可以反映出所有已提交的事务修改。这是事务的持久性保证。

Redo Log的工作原理

Redo Log的性能调优

0：事务提交时不强制写日志到磁盘，日志在后台刷新。这种配置性能高但风险较大。

1：每次事务提交时，Redo Log会立即刷入磁盘。这是默认的设置，确保了事务的强持久性。

2：事务提交时，日志写入文件系统缓存中，而不是立即写入磁盘，崩溃时可能丢失部分数据。

2.5 bin log（mysql）

Binlog的定义

Binlog是MySQL的二进制日志，记录了所有更改数据库数据的语句以及与其相关的事务。它与InnoDB存储引擎的Redo Log不同，Redo Log是用于恢复崩溃后未完成的事务，而Binlog是记录事务日志，用于备份、恢复和复制。

Binlog的作用

Binlog可以用作增量备份工具。通过定期备份Binlog文件，MySQL管理员可以将数据库恢复到某一时刻之前的状态，然后通过应用Binlog中的修改来恢复到崩溃前的最新状态。与完整备份配合，能够实现更精细的恢复过程。

如果数据库因某种原因崩溃，可以通过Point-in-Time Recovery（PITR，时间点恢复），将数据库恢复到特定的时间点，或恢复到某个已知的稳定状态。

MySQL支持主从复制（Replication），其中主服务器上的数据更改会通过Binlog同步到从服务器。主服务器会将所有更改记录到Binlog中，然后从服务器读取并应用这些日志，从而保持与主服务器的数据一致性。

这种机制使得可以创建冗余的从服务器来提高高可用性和读性能，分担查询负载。

三 、总结

InnoDB的Buffer Pool是MySQL用于缓存数据和索引页的内存区域，减少磁盘I/O，提升读写性能。Undo Log记录事务修改前的数据，用于回滚未提交的事务和实现MVCC。Redo Log则记录已提交事务的修改操作，确保系统崩溃后能够恢复事务，保证数据的持久性。Buffer Pool优化了内存使用，Undo Log维护事务一致性，Redo Log确保持久性与数据恢复，三者协同保障InnoDB的高效性与可靠性。