从MySQL5.5版本开始默认使用InnoDB作为引擎，它擅长处理事务，具有自动崩满恢复的特性，在日常开发中使用非常广泛，下面是言方的InnoDB引擎美构图，主要分为内存结构和磁盘结构两大部分。 

 内存结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。
Buffer Pool：缓冲池，简称BP。BP以Page页为单位，默认大小16K，BP的底层采用链表数据结构管理Page。在InnoDB访问表记录和索引时会在Page页中缓存，以后使用可以减少磁盘IO操作，提升效率。

缓冲池简单来说就是一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库性能的影响。在数据库中进行读取页的操作，首先将从磁盘读到的页存放在缓冲池中，这个过程称为将页"FIX"在缓冲池中。下一次再读取相同的页时，首先判断该页是否在缓冲池中。若在缓冲池中，称该页在缓冲池中被命中。直接读取该页。否则读取磁盘上的页。对于数据库中页的修改操作，则首先修改在缓冲池中的页，然后再以一定的频率刷新到磁盘上。这里需要注意的是，页从缓冲池刷新回磁盘的操作并不是每次页发生更新时触发，而是通过一种称为Checkpoint的机制刷新回磁盘。同样这也是为了提高数据库的整体性能。

对于innodb存储引擎而言，其缓冲池的配置通过参数innodb_buffer_ pool_size来设置。这是影响innodb性能的关键参数。具体来看，缓冲池中缓存的数据页类型有:索引页，数据页，undo页，插入缓冲(insert buffer)，自适应哈希索引(adaptive hash index)，innodb存储的锁信息(lock info)，数据字典信息(data dictionary）等。不能简单的认为，缓冲池只是缓存索引页和数据页，它们只是占缓冲池很大的一部分而已。

Page管理机制
  Page根据状态可以分为三种类型：
     ·free page：空闲page，未被使用
     ·clean page：被使用page，数据没有被修改过
     ·dirty page：脏页，被使用page，数据被修改过，页中数据和磁盘的数据产生了不一致

针对上述三种page类型，InnoDB通过三种链表结构来维护和管理
    ·free list：表示空闲缓冲区，管理free page
    ·flush list：表示需要刷新到磁盘的缓冲区，管理dirty page，内部page按修改时间排序。脏页即                       存在你flush链表，也在LRU链表中，但是两种互不影响，LRU链表负责管理page的                         可用性和释放，而flush链表负责管理脏页的刷盘操作。
    ·Iru list：表示正在使用的缓冲区，管理clean page和dirty page，缓冲区以midpoint为基点，前                      面链表称为new列表区，存放经常访问的数据，占63%；后面的链表称为old列表区，                      存放使用较少数据，占37%。
改进型LRU算法维护
    普通LRU：未尾淘汰法，新数据从链表头部加入，释放空间时从未尾淘汰
    改性LRU：链表分为new和old两个部分，加入元素时并不是从表头插入，而是从中间midpoint                         位置插入，如果数据很快被访问，那么page就会向new列表头部移动，如果数据没                         有被访问，会逐步向old尾部移动，等待淘汰。

                     每当有新的page数据读取到buffer pool时，InnoDb引擎会判断是否有空闲页，是否                         足够，如果有就将free page从free list列表删除，放入到LRU列表中。没有空闲页，                        就会根据LRU算法淘汰LRU链表默认的页，将内存空间释放分配给新的页。

BUffer pool配置参数：

show variables like%innodb_page_size%；/查看page页大小

show variables like 9%innodb_old%；//查看ru list中old列表参数

show variables like9%innodb_buffer%；//查看buffer pool参数

建议：将innodb_buffer_pool_size设置为总内存的60%-80%，innodb_buffer_pool_instances可以设置为多个，这样可以避免缓存争夺。|

从innodb1.0.x版本开始，允许有多个缓冲池实例。每个页根据哈希值平均分配到不同缓冲池实例中。这样做的好处是减少数据库内部的资源竞争。增加数据库的并发处理能力。通过参数innodb_buffer_pool_instances来进行配置。该值默认为1。在配置文件中将innodb_buffer_pool_instances设置为大于1的值就可以得到多个缓冲池实例。

注意：innodb_buffer_pool_size必须大于1GB，生成innodb_buffer_pool多实例才有效，最多支持64个innodb_buffer_pool实例。

 Change Buffer：写缓冲区，简称CB。在进行DML操作时，如果BP没有其相应的Page数据，并不会立刻将磁盘页加载到缓冲池，而是在CB记录缓冲变更，等未来数据被读取时，再将数据合并恢复到BP中。
ChangeBuffer占用BufferPool空间，默认占25%，最大允许占50%，可以根据读写业务量来进行调整。
参数innodb_change_buffer_max size；当更新一条记录时，该记录在BufferPool存在，直接在BufferPool修改，一次内存操作。如果该记录在BufferPool不存在（没有命中），会直接在ChangeBuffer进行一次内存操作，不用再去磁盘查询数据，避免一次磁盘1O。当下次查询记录时，会先进性磁盘读取，然后再从ChangeBuffer中读取信息合并，最终载入BufferPool中。
写缓冲区，仅适用于非准一普通索引页，为什么？
如果在索引设置唯一性，在进行修改时，InnoDB必须要做唯一性校验，因此必须查询磁盘，做一次I0操作。会直接将记录查询到BufferPool中，然后在缓冲池修改，不会在ChangeBufer操作。

Adaptive Hash Index：自适应哈希索引，用于优化对BP数据的查询。InnoDB存储引擎会监控对表索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
Log Bufer：日志缓冲区，用来保存要写入磁盘上log文件（Redo/Undo）的数据，日志缓冲区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到BLOB或多行更新的大事务操作时，增加日志缓冲区可以节省磁盘/O。
LogBuffer主要是用于记录InnoDB引擎日志，在DML操作时会产生Redo和Undo日志。
LogBuffer空间满了，会自动写入磁盘。
innodb_flush_log at trxrcommit参数控制日志刷新行为，默认为1
  0：每隔1秒写日志文件和刷盘操作（写日志文件LogBuffer->oS cache，刷盘OS cache->磁盘文          件），最多丢失1秒数据
 1：事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁10操作
 2：事务提交，立刻写日志文件，每隔1秒钟进行刷盘操伸

从上图大致可以看到innodb有多个内存块，可以认为这些内存块组成了一个大的内存池，负责如下工作：

1.维护所有进程/线程需要访问的多个内部数据结构。

2.缓存磁盘上的数据，方便快速的读取，同时在对磁盘文件的数据修改之前在这里缓存。

3.重做日志(redo log)缓冲

一.后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最新最近的数据。此外将已经修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常的情况下innodb能恢复正常的运行状态。

后台线程:

Innodb存储引擎是多线程的模型，因此其后台有多个不同的后台线程，负责处理不同的任务。

1.Master Thread

Master Thread 是非常核心的后台线程，主要负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新，合并插入缓冲(insert buffer)，undo页的回收等。

2.IO Thread

在innodb存储引擎中大量使用了AIO（Async IO）来处理写IO请求，这样可以极大提高数据库的性能。而IO Thread的工作主要负责这些IO请求的回调(call back)处理。在innodb 1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log IO thread。从innodb 1.0.x版本开始，read thread和write thread分别增大到了4个。可以使用innodb_read_io_threads和innodb_write_io_threads参数进行设置。

3. Purge Thread

事务被提交后，其使用的undo log可能不再需要，因此Purge Thread来回收已经使用并分配的undo页。在innodb 1.1 版本之前，purge操作仅在innodb存储引擎的Master Thread中完成。从innodb1.1版本开始，purge操作可以独立到单独的线程中进行。以此来减轻Master Thread的工作。从而提高CPU的使用率以及提升存储引擎的性能。可以通过在配置文件中添加如下参数来开启独立的Purge Thread(清洗线程)

 在innodb1.1版本中，即使innodb_purge_threads设为大于1，innodb存储引擎启动时也会将其设为1，从innodb1.2版本开始，innodb支持多个Purge Thread，这样做的目的是为了进一步加快undo页的回收。同时由于Purge Thread需要离散的读取undo页，这样可以更好的利用磁盘的随机读取性能。

4.Page cleaner Thread

page cleaner thread线程是在innodb 1.2.x的版本中引入的。其作用是将之前的版本中的脏页刷新操作都放入到单独的线程中来完成。而其目的是为了减轻原Master Thread的工作及对于用户查询线程的阻塞，进一步提高innodb存储引擎的性能。