mysqldump造成Buffer Pool污染的研究

　　其实作用就是：减小单次的大批量数据查询（类似于mysqldump的行为）对于BufferPool（下称BP）的污染。

　　BP可以被认为是一条长链表。被分成young 和 old两个部分，其中old默认占37%的大小（由innodb_old_blocks_pct配置）。靠近顶端的Page表示最近被放问。靠近尾端的Page表示长时间未被访问。而这两个部分的交汇处成为midpoint。每当有新的Page需要加载到BP时，该page都会被插入到midpoint的位置asp技术，并声明为old-page。当old部分的page，被访问到时，该page会被提升到链表的顶端，标识为young。

　　由于table scan的操作是先load page，然后立即触发一次访问。所以当innodb_old_blocks_time=0 时，会导致table scan所需要的page不读的作为young page被添加到链表顶端。而一些使用较为不频繁的page就会被挤出BP，使得之后的SQL会产生磁盘IO，从而导致响应速度变慢。这也就是标题中所提到的BP污染。

　　percona之前也做过相关测试，其结论是time=0时，正常访问的吞吐量下降为10%；当time=1000时，吞吐量和没有备份时的性能一致。

　　由结果可以看出，time=1000并没有给查询性能带来很大的提升。最佳情况下也只是比time=0时提高80%的性能。

　　其实不难理解，表中的concurrency很大程度上决定了测试page的冷热程度。并发数越大，每面产生的并行请求就越多，从而每个page被访问的频率就越高，page在LRU链表中的位置也就越靠顶端。反之亦然。

　　那么我们来想想下高频率热点数据访问时的情况。这时虽然mysqldump访问的page会不断加载在LRU顶端，但是高频度的热点数据访问会以更快的速度把page再次抢占到LRU顶端。从而导致mysqldump加载入的page会被迅速刷下，并立即被evict（淘汰）。因此，time=0或1000对这种压力环境下的访问不会造成很大影响，因为dump的数据根本抢占不过热点数据。

　　同样，超低频率的数据访问也是一样的情况。由于数据访问频度很低，大量的page都处于LRU链表的尾端。所以无论dump的page被加载到head或是midpoint位置，都会在热点数据的前面。也就是说无论怎样，数据page都会被淘汰。所以，这种压力环境下的性能同样不会随着time值的配置变化有很大浮动。

　　上图的曲线也证明了这样的观点。当innodb_old_blocks_pct 调节到60%时，波峰也相应平移到了 60%的位置。asp源码怎么搭建网站企业助理asp源码