**mysql的INNODB引擎是基于磁盘存储的，管理方式也是按照页管理的，表空间结构大概如下：
如果所有的请求都需要磁盘IO的话，那无疑是很耗时的，所以在中间就有一层缓存来进行缓冲，mysql的缓存池就是这个缓冲的角色，通过缓存池可以弥补部分cpu和磁盘的速度差距。
读操作
如果数据是首次读，那么按页读取后会将磁盘读出来页的数据存到缓存池，这样如果下次获取相同的页时，就不会区磁盘读取，而直接返回缓存池中的数据页。
写操作
要写数据肯定需要先获取数据，那么首先会读，然后，对要写的数据并不会直接被写入到磁盘，而实先修改缓存池中的页，然后根据一定的频率来将这个脏页（dirty page）刷到磁盘，这里又涉及到**checkpoint**机制。
缓存池中主要包含了以下部分
- 数据页
- 索引页
- 插入缓存
- 自适应哈希索引
- 锁信息
- 数据字典信息
缓存池中的每个缓存页又包含以下控制信息，称为控制块
- space id _表空间编号
- page numeber _页号
- 页地址 _在bufferPool中的地址
- 锁信息以及 LSN 信息日志序列号
- 其他信息
缓存池的管理
缓存池中大部分是数据页和索引页，为了管理这些页，就有free链表，lru链表和flush链表。
mysql服务启动时，buffer pool初始化，buffer pool被划分为控制块和缓存块，此时这些缓存页是空的，随着服务的使用，不断会有磁盘数据页被刷到缓存中，为了记录哪些是缓存页使用了的，哪些缓存页是空闲的，在一开始，就将这些缓存页的控制单元记录到free链表中，这样就可以通过free链表来管理缓存页，当需要使用缓存页时，从free链表申请空闲的缓存页，然后让lru链表的节点记录该页的控制单元信息，这样，就将使用的和空闲的分开来，同时，合理的淘汰掉不常用的缓存页，将空页还给free链表；对于写请求造成的脏页，会在一个flush链表中记录它的信息，不同的是，flush链表记录的是它在lru链表的信息，这样就可以最终找到脏页，再把脏页刷到磁盘。
- 对于lru链表中节点的快速定位，是使用了一个哈希表来处理的，
哈希表的key是使用缓存页的space id _表空间编号 + page numeber _页号组成的，而value则是缓存页，这样就不需要遍历链表，O(1)时间就能找到缓存页。 - 对于lru的淘汰策略，则是链表被分为了新生代和老生代，新生代和老生代的比例为5：3，对于链表中已有的数据页。
- 节点被访问时，如果是新生代的节点，则会被移动到链表的head节点；
- 如果是老生代的节点，那么当这个节点被访问时，已经在链表中存在了1s以上，则会把它移动到head节点，否则，保持当前位置。
- 如果是新加入一个数据页，则是将它放到老生代的o1节点，如果当前链表容量达到了innodb_buffer_pool_size（大约占物理内存的60%-80%），还需要移除tail节点；
mysql在做全表扫描时，在server层是这么执行的
对执行层返回的结果整合成结果集，发送到mysql的net-buffer,
net-buffer满了以后如果引擎层还没查询完成，net-server就会调用网络接口发送数据到客户端，然后清空net-buffer，来接收后续的结果。
如果发送函数返回 EAGAIN 或 WSAEWOULDBLOCK，就表示本地网络栈（socket send buffer）写满了，进入等待。直到网络栈重新可写，再继续发送。
在INNODB执行引擎层内存页是受buffer-pool管理的，对于全表扫描这种场景，数据中非热点数据居多，基本会被放到old，不会影响young的内存数据，也就不会使热点缓存页失效。缓存页置换导致大量磁盘io，从而影响mysql的性能
