mysql特点_Mysql 三大特性详解

Mysql Innodb后台线程

工作方式

首先Mysql进程模型是单进程多线程的。所以我们通过ps查找mysqld进程是只有一个。

体系架构

InnoDB存储引擎的架构如下图所以，是由多个内存块组成的内存池，同时又多个后台线程进行工作，文件是存储磁盘上的数据。

后台线程

上面看到一共有四种后台线程，每种线程都在不停地做自己的工作，他们的分工如下:

Master Thread: 是最核心的线程，主要负责将缓冲池中的数据异步刷新的磁盘，保证数据的一致性，包括脏页的刷新、合并插入缓冲(INSERT BUFFER),UNDO页的回收等。下面几个线程其实是为了分担主线程的压力而在最新的版本中添加的。

IO Thread: InnoDB使用大量的异步IO来处理请求。IO Thread的主要工作就是负责IO请求的回调(call back)处理。异步IO可以分为4个，分别是:write, read, insert buffer 和 log IO thread。

Purge Thread: undo log是用来保证事务的，当一个事务正常提交后，这个undo log可能就不再使用了。purge thread就是用来清除这部分log已经分配的undo页的。

Page Cleaner Thread: 主要是把脏页的刷新从主线程中拿到单独的线程，减轻主线程的压力，减少用户查询线程的阻塞，提高整体性能。

Mysql Innodb内存结构

具体来看缓冲池中缓存的数据页类型有:

索引页: 缓存数据表索引

数据页: 缓存数据页，占缓冲池的绝大部分

undo页: undo页是保存事务，为回滚做准备的。

插入缓冲(Insert buffer): 上面提到的插入数据时要先插入到缓存池中。

自适应哈希索引(adaptive hash index): 除了B+ Tree索引外，在缓冲池还会维护一个哈希索引，以便在缓冲池中快速找到数据页。

InnoDB存储的锁信息(lock info):

数据字典(data dictionary):

内存中除了缓冲池外外还有:

重做日志缓冲redo log: 为了避免数据丢失的问题，当前数据库系统普遍采用了write ahead log策略，既当事务提交时先写重做日志，再修改写页。当由于发生宕机而导致数据丢失时，可以通过重做日志进行恢复。InnoDB先将重做日志放到这个缓冲区，然后按照一定的频率更新到重做日志文件中。重做日志一般在下列情况下会刷新内容到文件:

1.Master Thread每一秒将重做日志缓冲刷新到重做日志文件

2.每个事务提交时会将重做日志缓冲刷新到重做日志文件

3.当重做日志缓冲池剩余空间小于1/2时，重做日志缓冲刷新到重做日志文件

额外内存池: InnoDB存储引擎中，对内存的管理师通过一种称为内存堆的方式进行的，在对一些数据结构本身的内存进行分配时，需要从额外的内存池中进行申请，当该区域的内存不够时，会从缓冲池中进行申请。

缓冲池是一个很大的内存区域，InnoDB是如何对这些内存进行管理的呢。答案就使用LRU list。

LRU(Latest Recent Used, 最近最少使用)算法默认的是最近使用的放到表头，最早使用的放到表尾，依次排列。当有LRU填满时有新的进来就把最早的淘汰掉。InnoDB则是在这个基础上进行了修改:

最近使用的不放到表头，而是根据配置放到一定比例处，这个地方叫做midpoint, midpoint之前的成为new列表，之后的成为old列表。淘汰的同样是表尾的页。

为了保证new列表的不经常使用时能够淘汰，设置了一个超时时间:innodb_old_blocks_time，当数据在midpoint(我理解应该是在old列表中，不然这个点的页就一个，变化也比较频繁)的时间超过找个时间时就会被提升到表头，new列表的表尾页则被置换到old列表中。

这么做的原因主要是因为常见的索引或数据的扫描操作会连续读取大量的页，甚至是全表扫描。如果采用原来的LRU算法就会更新全部的缓冲池，其他查询需要的热点数据就会被冲走，导致更多的磁盘读取操作，降低数据库的性能。

LRU是用来管理已经读取的页，当数据库启动时LRU是空列表,既只有表头，没有内容。这时页都放在Free List中。当需要有数据读写时要进行需要获取