Mysql的全表扫描策略

全表扫描对server层的影响

现在要对一个大的数据库进行全表扫描，实际上是直接扫描表的主键索引。查到的每一行都可以直接放到结果集里面，然后返回给客户端。实际上，服务端不需要保存一个完整的结果集。流程如下：

1. 获取一行，写到net_buffer中。这块内存的大小是由参数net_buffer_length定义的，默认是16k。

2. 重复获取行，直到net_buffer写满，调用网络接口发出去。

3. 如果发送成功，就清空net_buffer，然后继续取下一行，并写入net_buffer。

4. 如果发送函数返回EAGAIN或WSAEWOULDBLOCK，就表示本地网络栈（socket send buffer）写满了，进入等待。直到网络栈重新可写，再继续发送。

MySQL是“边读边发的”，这个概念很重要。这就意味着，如果客户端接收得慢，会导致MySQL服务端由于结果发不出去，这个事务的执行时间变长。

   如果state的值一直显示在sending to client的状态，那么一个线程处于“等待客户端接收结果”的状态。这个与上一篇文章中的-quick的参数有关。

sending to client状态与Sending data状态

• sending to client仅当等待客户端接收结果才会显示。
• Sending data指的是以下几个阶段：

1. MySQL查询语句进入执行阶段后，首先把状态设置成“Sending data”；
2. 然后，发送执行结果的列相关的信息（meta data) 给客户端；
3. 再继续执行语句的流程
4. 执行完成后，把状态设置成空字符串。

 “Sending data”并不一定是指“正在发送数据”，而可能是处于执行器过程中的任意阶段。如以下场景：

session B明显是在等锁，状态显示为Sending data

 

全表扫描对InnoDB的影响

InnoDB内部作全表扫描的是，内存的数据页是在Buffer Pool (BP)中管理的，它使用的是最近最少使用 (Least Recently Used, LRU)算法，这算法就不详细说了。主要看，如果我们要扫描一个很大的表，那么当前内存里面的数据页就有可能全部淘汰掉。而InnoDB在这个的基础上做了改进。

在InnoDB实现上，按照5:3的比例把整个LRU链表分成了young区域和old区域。图中LRU_old指向的就是old区域的第一个位置，是整个链表的5/8处。也就是说，靠近链表头部的5/8是young区域，靠近链表尾部的3/8是old区域。

改进后的LRU算法执行流程变成了下面这样。

1. 状态1，要访问数据页P3，由于P3在young区域，因此和优化前的LRU算法一样，将其移到链表头部，变成状态2。

2. 之后要访问一个新的不存在于当前链表的数据页，这时候依然是淘汰掉数据页Pm，但是新插入的数据页Px，是放在LRU_old处。

3. 处于old区域的数据页，每次被访问的时候都要做下面这个判断：

• 若这个数据页在LRU链表中存在的时间超过了1秒，就把它移动到链表头部；
• 如果这个数据页在LRU链表中存在的时间短于1秒，位置保持不变。1秒这个时间，是由参数innodb_old_blocks_time控制的。其默认值是1000，单位毫秒。

那么全局扫描就会变成这样的逻辑。

1. 扫描过程中，需要新插入的数据页，都被放到old区域;

2. 一个数据页里面有多条记录，这个数据页会被多次访问到，但由于是顺序扫描，这个数据页第一次被访问和最后一次被访问的时间间隔不会超过1秒，因此还是会被保留在old区域；

3. 再继续扫描后续的数据，之前的这个数据页之后也不会再被访问到，于是始终没有机会移到链表头部（也就是young区域），很快就会被淘汰出去。

这样子，全表扫描也用到了buffer pool，但是对young区域几乎没有影响，保证了页命中率。