一 、上期回顾
上次小编讲了一条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的高效性与可靠性。