InnoDB存储引擎
mysql 存储引擎（好难用，看https://www.zybuluo.com/eqyun/note/27850）
简介
InnoDB是事务安全的MySQL存储引擎，从MySQL5.5版本开始是默认的表存储引擎，是第一个完整支持ACID事务的MySQL存储引擎，其特点是行锁设计、支持MVCC、支持外键、提供一致性锁定读，同时被设计用来最有效地利用以及使用内存和CPU
InnoDB存储引擎体系架构
后台线程(多个)->InnoDB存储引擎内存池->物理文件
后台线程
1. Master Thread
核心的后台线程，负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新、合并插入缓冲(INSERT BUFFER)、 UNDO页的回收等
2. IO Thread
在InnoDB中大量使用了AIO（Async IO）来处理IO 请求，IO Thread主要是负责这些IO请求的回调处理。Io Thread共有4类：write、read、insert buffer和log IO thread。在InnoDB 1.0.x 版本开始，read thread和write thread分别增加大4个，用innodb_file_io_threads和innodb_write_io_threads参数来设置，如
可以看到thread 0为insert buffer thread,IO thread 1为log thread.
mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
....
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
3. Purge Thread
事务提交后，使用的undolog可能不再需要，因此需要PurgeThread 来回收已经使用并分配的undo页面。在InnoDB1.1版本前，它是在Master线程中完成的，InnoDB1.1后，独立一条线程。在配置文件中 启用独立Purge Thread线程配置为：
[mysqld]
innnodb_purge_threads=1
在1.2版本后支持多个Purge Thread，加书undo页的回收，可用以后语句查询：
mysql> show variables like 'innodb_purge_threads'\G;
*************************** 1. row ***************************
Variable_name: innodb_purge_threads
Value: 1
1 row in set (0.00 sec)
ERROR:
No query specified
4. Page Cleaner Thread
Page Cleaner Thread是在InnoDB 1.2x版本加入的，作用是将之前版本中脏页的刷新操作都加入到单独的线程中完成，目的是为了减轻原Master Thread的工作和用户查询线程的阻塞。
内存
1. 内存池
InnoDB是基于磁盘存储的，并将记录按照页的方式进行管理，内存池就是为了解决CUP速度与磁盘速度之间的鸿沟。
在数据库中进行记取页的操作，首先将磁盘的页放到缓冲池，这个过程称将页FIX在缓冲池。下一次再读相同的页时，首先读缓冲池，有直接读，没有再去读磁盘
对数据库中页的修改也首先修改缓冲池，再以一定的频率刷新到磁盘上。缓冲池的大小直接影响数据库的整体性能
在InnoDB下，其缓冲池配置可通过innodb_buffer_pool_size来设置，查询语句为：
mysql> show variables like 'innodb_buffer_pool_size'\G;
*************************** 1. row ***************************
Variable_name: innodb_buffer_pool_size
Value: 134217728
1 row in set (0.01 sec)
缓冲池缓存的数据页类型有：索引页、数据据、undo页、插入缓冲(insert buffer)、自适应哈希索引(adaptive hash index)、InnoDB的锁信息(lock info)、数据字典信息(data dictionary)等
从InnoDB 1.0.x版本开始，允许多个缓冲池实例，这样做的好处是减少数据库内部的资源竞争，增加数据库的并发能力，可以通过innodb_buffer_pool_instances来配置，默认为1，查询语句为：
mysql> show variables like 'innodb_buffer_pool_instances'\G;
*************************** 1. row ***************************
Variable_name: innodb_buffer_pool_instances
Value: 1
1 row in set (0.00 sec)
查看缓冲池的使用状态可以通过以下语法查询：
mysql> use information_schema;
Database changed
mysql> select pool_id,pool_size,free_buffers,database_pages from INNODB_BUFFER_POOL_STATS\G;
*************************** 1. row ***************************
pool_id: 0
pool_size: 8192
free_buffers: 7606
database_pages: 586
1 row in set (0.00 sec)
2. LRU List、Free List和 Fush List
主要设计对内存池的管理，算法理论太强，看得头痛
通常来说，数据库中的缓冲池是通过LRU(Lastest Recent Used,最近最少使用)算法来管理的。
在InnoDB中，缓冲池页的大小默认为16k
LRU List:最频繁使用的页在LRU列表的首端，最少使用的在尾端，先释放尾端的页
InnoDB中，优化了LRU算法，在列表中加入了midpoint位置，就是说，新加入的页不是直接放在首部，而是放在LRU列表中的 midpoint位置，这个算法称为midpoint insertion strategy，默认下该位置 是在LRU列表长度的5/8，可通过innodb_old_blocks_pct控制(谁他妈的鸟你)
mysql> show variables like 'innodb_old_blocks_pct'\G;
*************************** 1. row ***************************
Variable_name: innodb_old_blocks_pct
Value: 37
1 row in set (0.00 sec)
在innoDB中，midpoint之后的列表称为old列表，之前的为new列表
优化还加入了另一个参数innodb_old_blocks_time，用来表示页读取到mid位置后需要等待多久才会被加入到LRU列表的new列表，因此可以通过修改这个值来尽可以使LRU列表中的热点数不被刷出。
mysql> show variables like 'innodb_old_blocks_time'\G;
*************************** 1. row ***************************
Variable_name: innodb_old_blocks_time
Value: 0
1 row in set (0.00 sec)
够狠，默认为0
当页从LRU列表的old部分加入new部分，这个操作称为page make young,而因innodb_old_blocks_time的设置而导致没有从old移动new的操作称为page not make young，可以通过以下方法查看：
mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
141024 7:50:59 INNODB MONITOR OUTPUT
=====================================
....
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 219529
Buffer pool size 8192
Free buffers 5528
Database pages 2661
Old database pages 1002
Modified db pages 374
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 2655, created 6, written 41
40.57 reads/s, 0.12 creates/s, 0.80 writes/s
Buffer pool hit rate 986 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 2661, unzip_LRU len: 0
I/O sum[0]:cur[32], unzip sum[0]:cur[0]
可以看到buffer pool size有8192,即8198*16=127M左右，（真少）
Free buffers表示当前Free列表中页的数量，
Database pages表示LRU列表页的数量
youngs/s表示第秒page make young的次数
non_yongs/s:每秒page not make young的次数
重要：Buffer pool hit rage,表示缓冲池的命中率，这个通常不小于95%，如果小于95%，请观察是否由于全表扫描引起的LRU列表被污染
可以通过以下语法看缓冲池的使用情况：
mysql> select pool_id,hit_rate,pages_made_young,pages_not_made_young from information_schema.innodb_buffer_pool_stats\G;
*************************** 1. row ***************************
pool_id: 0
hit_rate: 998
pages_made_young: 6580
pages_not_made_young: 0
1 row in set (0.00 sec)
可以通过以下语句看LRU表的暗体情况：
mysql> select table_name,space,page_number,page_type from innodb_buffer_page_lru where space=1;
Empty set (0.16 sec)
没东西....
InnoDB支持压缩功能，原来16K的页压缩为1K
LRU列表中的页被修改后，称为脏页(dirty page)，即缓冲页面上的数据产生了不一致，这时候数据库会通过CHECKPIOINT机制将脏页刷新回磁盘，即Flush列表中的页为脏页列表。
在show engine innodb status中
Modified db pages为是脏页数目
3. 重做日志缓冲
InnoDB内存区除了缓冲池外，还有重做日志缓冲(redolog buffer)。Innodb首先将重做日志放到这个缓冲，再一定频率刷新到重做日志文件。重做缓冲不用太多，因为每一秒就会刷新到日志文件，默认为8M，可通过innodb_log_buffer_size控制
把日志缓冲刷新到日志文件中的情况有以下三种 ：
a. Master Thread每一秒将重做日志缓冲刷新到重做日志文件中
b. 每个事务提交时
c.当重做日志缓冲池剩余空间小于1/2时
4. 额外的内存池
在InnoDB中，对内存的管理是通过一种 称为内存堆 （heap)的方式进行的，在对一些数据结构本身的内存进行分配 时，需要从额外内存池中申请，当该区不够时，会从缓冲池中申请。
例如：分配 了多个缓冲池，但是每个缓冲池的帧缓冲(frame buffer)还有对应的缓冲控制对象(buffer contrl block)，这些对象记录一些如LRU、锁、等待等信息
CheckPoint
上面提到需要把脏页刷新到磁盘，若每一次弄脏的页都刷新，那开销太大，但是如果脏了不刷新，突然停电死机了，那数据就不能恢复了。为了避免这种情况，事务数据库都采用了Write Ahead Log策略，就是当事务提交时，先做重做日志，再修改页。当死机时，可以通过重做日志来完成数据的恢复。
CheckPoint是为了解决以下问题：
a. 缩短数据库的恢复时间
b. 缓冲池不够用时，将脏页刷新回磁盘
c. 重做日志不可用时，刷新脏页
CheckPoint分两种 ：
a. Sharp Checkpoint
b. Fuzzy Checkpoint
Sharp Checkpoint 发生 在数据库关闭时将所有的脏页刷回磁盘
在数据库运行时运行的是Fuzzy Checkpoint,就是只刷新一部分脏页，而不是刷新所有的脏页
Fuzzy CheckPoint分以下几种 情况：
a. Master Thread Checkpoint
b. Flush_lru_list checkpoint
c. Async/Sync Flush Checkpoint
d. Dirty Page too much Checkpoint
Master Thread Checkpoint 差不多以每秒的速度从缓冲池刷新一定比例回磁盘
Flush_lru_list checkpoint是在移除LRU列表的尾端的页面时，刷新脏页的操作
Ayync/Sync Flush Checkpoiint是在重做日志不可用时，强制刷新
Dirty page too mush是在脏页太多的情况下，强制刷新。可用 innodb_max_dirty_pages_pct来控制
来源：https://www.cnblogs.com/ultrazb/p/4049218.html