InnoDB 的数据是保存在主键索引上的,所以全表扫描实际上是直接扫描表 t 的主键索引。这条查询语句由于没有其他的判断条件,所以查到的每一行都可以直接放到结果集里面,然后返回给客户端。
那么,这个“结果集”存在哪里呢?实际上,服务端并不需要保存一个完整的结果集。取数据和发数据的流程是这样的:
net_buffer
中。这块内存的大小是由参数net_buffer_length
定义的,默认是 16k。net_buffer
写满,调用网络接口发出去。net_buffer
,然后继续取下一行,并写入net_buffer
。通过上面的流程,可以发现,MySQL 是“边读边发的”,这个概念很重要。这就意味着,如果客户端接收得慢,会导致 MySQL 服务端由于结果发不出去,这个事务的执行时间变长。
如果客户端使用–quick
参数,会使用mysql_use_result
方法。这个方法是读一行处理一行。因此可以想象一下,假设有一个业务的逻辑比较复杂,每读一行数据以后要处理的逻辑如果很慢,就会导致客户端要过很久才会去取下一行数据,可能就会出现服务端阻塞的现象。
因此,对于正常的线上业务来说,如果一个查询的返回结果不会很多的话,建议使用mysql_store_result
这个接口,直接把查询结果保存到本地内存。
InnoDB 管理 Buffer Pool 的 LRU 算法,是用链表来实现的。
假设按照这个算法,我们要扫描一个 200G 的表,而这个表是一个历史数据表,平时没有业务访问它。那么,按照这个算法扫描的话,就会把当前的 Buffer Pool 里的数据全部淘汰掉,存入扫描过程中访问到的数据页的内容。也就是说 Buffer Pool 里面主要放的是这个历史数据表的数据。
对于一个正在做业务服务的库,这可不妙。你会看到,Buffer Pool 的内存命中率急剧下降,磁盘压力增加,SQL 语句响应变慢。
这个策略,就是为了处理类似全表扫描的操作量身定制的。还是以刚刚的扫描 200G 的历史数据表为例,我们看看改进后的 LRU 算法的操作逻辑:
可以看到,这个策略最大的收益,就是在扫描这个大表的过程中,虽然也用到了 Buffer Pool,但是对 young 区域完全没有影响,从而保证了 Buffer Pool 响应正常业务的查询命中率。
原文:https://www.cnblogs.com/weiweng/p/12491027.html