内存缓冲池

buffer pool，如果mysql不使用内存缓冲池，每次读取数据时，都需要访问磁盘，会大大的增加磁盘的IO请求，导致效率低下；在Innodb引擎在读取数据的时候，把相应的数据和索引载入到内存的缓冲池（buffer pool）中，一定程度的提高了数据的读写速度

buffer pool

占用大量内存，用来存放各种数据的缓存包括：索引页，数据页，undo页，插入缓冲，自适应哈希索引，innodb存储的锁信息，数据字典等。工作方式是将数据库文件按照页（每页16k）读取到缓冲池，然后按照最近最少使用算法（LRU）来保留缓冲池中的缓冲数据。如果数据库文件需要修改，总是首先修改在缓冲池中的页（发生修改后即成为脏页），然后在按照一定的频率将缓冲池中的脏页刷新到文件

表空间

表空间可以看作是InnoDB存储引擎逻辑结构的最高层。表空间文件：InnoDB默认的表空间文件为ibdata1

• 页：每页数据为16kb，且不能进行修改。常见的页类型有：数据页，Undo页，系统页，事务数据页，插入缓冲位图页，插入缓冲空闲列表页，未压缩的二进制大对象页，压缩的二进制大对象页

• 区：由64个连续的页组成，每个页大小为16kb，即每个区的大小为1024kb即1MB

• 段：表空间由各个段组成，常见的段有数据段，索引段，回滚段（undo log段）等

redo log和undo log

mysql中的原则是日志先行。为了满足事务的持久性，防止buffer pool数据丢失，innodb引入了redo log。为了满足事务的原子性，innodb引入了undo log

redo log

redo log就是保存执行的SQL语句到一个指定的log文件，当mysql进行数据恢复的时候，重新执行redo log记录的SQL操作即可。引入buffer pool会导致更新的数据不会实时地将数据持久化到硬盘，当系统崩溃时，虽然buffer pool中的数据丢失，数据没有持久化。但是系统可以根据redo log的内容，将所有数据恢复到最新的状态。redo log在磁盘上作为一个独立的文件存在，默认情况下会有两个文件，名称分别为ib_logfile0和ib_logfile1

innodb_additional_mem_pool_size = 100M
innodb_buffer_pool_size = 128M
innodb_data_home_dir = /home/mysql/local/mysql/var
innodb_data_file_path = ibdata1:1G：autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 128M
innodb_log_file_in_group = 2
innodb_log_group_home_dir = /home/mysql/local/mysql/var

redo log的记录内容

undo log和redo log本身是分开的。Innodb的undo log是记录在数据文件（ibd）中的，而且innodb将undo log的内容看做是数据，因此对undo log本身的操作（如向undo log插入一条undo log记录等），都会记录redo log。undo log可以不必立即持久化到磁盘上。即便丢失了，也可以通过redo log将其恢复。因此当插入一条记录时：

• 向undo log插入一条undo log记录

• 向redo log中插入一条“插入undo log记录”的redo log记录

• 插入数据

• 向redo log插入一条“insert”的redo log记录

在一个事务中插入数据的时候：

假设对两个字段A，B分别进行更新，初始值分别为1，3
begin
在undo log中记录A为1
更新A为2
记录A=2到redo log在undo log中记录B为3
更新B为4
记录B=4到redo log将redo log写入到磁盘
commit

redo log的io性能

为了保证redo log能够有很好的io性能，innodb的redo log的设计有以下几个特点：

• 尽量保持redo log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。以顺序追加的方式记录redo log

• 批量写入日志。日志并不是直接写入到文件，而是先写入redo log buffer，然后每秒钟将buffer中数据一并写入磁盘

• 并发的事务共享redo log的存储空间，他们的redo log按语句的执行顺序，依次交替的记录在一起，以减少日志占用的空间

• redo log上只进行顺序追加的操作，当一个事务需要回滚时，它的redo log记录也不会从redo log中删除

undo log

为了满足事务的原子性，在操作任何数据之前，首先将数据备份到undo log，然后进行数据的修改。如果出现了错误或者用户手动执行了rollback，系统可以利用undo log中的备份将数据恢复到事务开始之前的状态。与redo log不同的是，磁盘上不存在单独的undo log 文件，他存放在数据库内部的特殊段（segment）中，这称之为undo段（undo segment），undo段位于共享表空间内
Innodb为每行undo log记录都实现了三个隐藏字段：

• 6字节的事务ID（DB_TRX_ID）

• 7字节的回滚指针（DB_ROLL_PTR）

• 隐藏的ID

redo log和undo log

• 数据持久化

1. pool中维护一个按脏页修改先后顺序排列的链表，叫flush_list。根据flush_list中页的顺序刷数据到持久化存储。按页面最早一次被修改的顺序排列。正常情况下，dirty page刷新数据的时机为：

   1. 当redo空间占满时，将会将部分dirty page flush到disk上，然后释放部分redo log内容

   2. 当需要buffer pool分配一个page，但是已经满了，这时候必须flush dirty pages to disk。

   3. 检测到系统空闲的时候

• 数据恢复
  随着时间积累，redo log会变得很大。如果每次都从第一条记录开始恢复，恢复过程会十分缓慢，从而无法被容忍。为了减少恢复的时间，就引入了checkpoint机制：假设在某个时间点，所有的脏页都被刷新到了磁盘上。这个时间点之前的所有redo log就不需要重做了。系统记录下这个时间点时redo log的结尾位置作为checkoutpoint。在进行恢复时，从这个checkpoint的位置开始即可。checkpoint点之前的日志就不再需要了，可以被删除掉