MySQL：（二）存储引擎
一、存储引擎
1. InnoDB
在MySQL现版本，默认的存储引擎是InnoDB，这个不用多说了，另外常见的还有MyISAM，Memory，CSV等，这里就InnoDB进行介绍。
总结成三个词语就是：事务，外键，行级锁。
2. idb文件-表空间文件
- *.frm：与表相关的元数据信息都存放在frm文件，包括表结构的定义信息等
- *.ibd：InnoDB DATA，表数据，表结构和索引的文件。该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。
要是想查看这个表，直接打开的话是不行的，因为都是二进制文件
可以通过ibd2sdi xx.ibd命令来得到json格式的表数据
3. 逻辑存储结构
二、架构
1. 内存架构
buffer pool处理主键索引、二级索引，而change buffer是基于为了减少磁盘io的目的，优化了二级索引处理。
利用哈希索引去做查操作非常的快，而使用b+树的效率和使用hash索引相比就没有那么高，因此在innodb中优化了对buffer pool的查询。如果hash索引更快则建立hash索引，和之前学的一样，和b+树都是一种数据结构。
2. 磁盘架构
3. 后台线程
后台线程负责将InnoDB存储引擎缓冲池中的数据，在合适时间刷新到磁盘。
三、事务原理
这里介绍两个日志：redo log和undo log，锁和MVCC博客戳下面链接：
MySQL：（三）全局锁、表级锁、行级锁 | 颓废市民黄先生 (rengoku.top)
MySQL：（四）事务隔离级别和MVCC | 颓废市民黄先生 (rengoku.top)
1. redo log
当执行DML操作的时候，如果在内存的buffer pool不存在需要的数据，会通过后台线程将数据从ibd文件中刷新过去。
可能会问为什么不是将修改的数据存储在change buffer？
因为刚刚介绍了，change buffer针对二级索引的数据，而现在是通用的情况
此时在内存中的脏页，后台线程会在合适的时机将数据写回磁盘，将数据整合保证数据一致性。
如果此时事务已经提交了，但是写磁盘的时候失败了怎么办？
这个问题就是redo log起作用的地方。我们回到脏页刷新到磁盘之前：
redo log会将数据页变化写在log buffer中的redolog buffer（不记得看内存架构那里），在事务提交的时候，会将数据页变化直接刷新到磁盘当中。之后进行脏页刷新的时候，如果刷新出错了，就可以通过redo log进行恢复。redo log会记录数据的单次变化，所以可以通过redo log进行数据恢复。
我在事务提交的时候直接将数据备份到磁盘中不行吗，为什么要使用redo log？
redo log支持Write-Ahead Logging（WAL）机制，即数据库系统首先将事务操作记录到redo log，然后异步地将这些操作应用到磁盘上的数据文件。这种机制允许数据库快速响应事务操作，同时通过redo log保证了数据的持久性和一致性，从而提高了数据库的整体性能。
如果没有redo log，数据库系统需要在每次事务提交时都立即将数据写入磁盘，这会增加大量的I/O操作，降低数据库的性能。
redo log还有什么作用？
数据持久性与一致性
redo log是数据库的事务日志，用于记录事务操作的细节，包括插入、更新和删除等。它确保了数据的持久性，即使在数据库发生崩溃或异常重启后，也能通过redo log来还原事务操作，从而维护数据的一致性。
当数据库因崩溃而不正常关闭时，redo log可以用于回滚尚未持久化到磁盘的事务更改，将数据库还原到一致的状态，这是数据库恢复的重要手段。
支持备份与恢复
redo log也用于数据库的备份和恢复过程。备份可以在不中断数据库运行的情况下进行，并且可以使用redo log来还原备份数据，这对于灾难恢复和备份策略非常重要。
支持数据库复制
在分布式系统中，redo log可以用于数据库复制，以将一个数据库的更改传播到另一个数据库。这有助于实现高可用性、负载平衡和数据复制。
2. undo log
