由于table scan的操作是先load page，然后立即触发一次访问。所以当innodb_old_blocks_time =0 时，会导致table scan所需要的page不读的作为young page被添加到链表顶端。而一些使用较为不频繁的page就会被挤出BP，使得之后的SQL会产生磁盘IO，从而导致响应速度变慢。
这时虽然mysqldump访问的page会不断加载在LRU顶端，但是高频度的热点数据访问会以更快的速度把page再次抢占到LRU顶端。从而导致mysqldump加载入的page会被迅速刷下，并立即被evict（淘汰）。因此，time=0或1000对这种压力环境下的访问不会造成很大影响，因为dump的数据根本抢占不过热点数据。不只dump，当大数据操作的时候也是如此。
二、mysql系统层面优化 1.关闭 numa=off,或修改策略为interleave(交织分配内存)防止意外的swapnuma策略引入了node的概念，每个物理CPU都被视为一个node，而每个node都有一个local memory，相对这个node之外的其它node都属于外部访问。
NUMA的内存分配策略有localalloc（默认）、preferred、membind、interleave。
localalloc规定进程从当前node上请求分配内存；
preferred比较宽松地指定了一个推荐的node来获取内存，如果被推荐的node上没有足够内存，进程可以尝试别的node。
membind可以指定若干个node，进程只能从这些指定的node上请求分配内存。
interleave规定进程从指定的若干个node上以Round-roll算法交织地请求分配内存。
每个进程（或线程）都会分配一个优先node,对于系统默认的localalloc策略会有一个问题，对于mysql这种几乎占满整个系统内存的应用来说，很容就把某个node的资源给占满，若Linux又把一个大的资源分配到这个已经占满资源的node时，会资源不足，造成内存数据于磁盘进行交换，或者摒弃buffer_pool里的活跃数据。在实际测试中发现比如有node0、node1 两个物理node，当系统负载很高的时候，node0资源被占满，node1虽然仍有部分空闲内存，但是系统即使进行内存到磁盘交换也不会去利用node1上的空闲资源。
因此建议对于像mysql这样的单实例的庞大复杂的进程来说，关闭numa或者设置策略为交织分配内存更合理。但对于一个机器上有多少个实例，可以每个实例绑定一个CPU核上。然后就可以充分利用numa的特性，更高效。
2.增加本地端口，以应对大量连接echo ‘1024 65000′ > /proc/sys/net/ipv4/ip_local_port_range
该参数指定端口的分配范围，该端口是向外访问的限制。mysql默认监听的3306端口即使有多个请求链接，也不会有影响。但是由于mysql是属于高内存、高cpu、高io应用，不建议把多少应用于mysql混搭在同一台机器上。即使业务量不大，也可以通过降低单台机器的配置，多台机器共存来实现更好。
3.增加队列的链接数echo ‘1048576’ > /proc/sys/net/ipv4/tcp_max_syn_backlog
建立链接的队列的数越大越好，但是从另一个角度想，实际环境中应该使用连接池更合适，避免重复建立链接造成的性能消耗。使用连接池，链接数会从应用层面更可控些。
4.设置链接超时时间echo ’10’ > /proc/sys/net/ipv4/tcp_fin_timeout
该参数主要为了降低TIME_WAIT占用的资源时长。尤其针对http短链接的服务端或者mysql不采用连接池效果比较明显。
三、其它层面优化的考虑对于高DAU的业务mysql实例来说，建议不要吝惜内存，使用128G或更高内存，innodb很好的利用了内存的优势来提高mysql的性能，我们就要给予他足够的空间来发挥他的性能。磁盘IO性能远不及内存的处理速度，这个无可厚非，所做的优化尽量的把需求IO的操作阻拦到内存直接返回给客户端。
当然内存再高也不能把所有的数据都缓存到内存中，在实际的大部分业务中还是依赖随机IO居多，更如现今比较火的手游，更是高随机写入的业务类型，各个云厂商也都默认提供SSD甚至需求更高的PCIe Flash存储设备。通过提高磁盘的IO性能也是其次的选择。
另业务如果足够大，单台机器必然无法支撑，就要考虑分库，分表，大部分产品公司所做的还是按业务划分库。如果一项业务也大到单台机器无法承受，那就需要分表和分库来操作了。其实不管业务是否会做大，当开始建立工程的时候都应该要做到支持可分库、可分表（尽量避免使用表的自增ID作为业务ID使用）、可分业务(尽量避免事务操作，甚至允许在业务上有些可接受的牺牲，否则后期很难划分业务)，否则只有面临重构的尴尬场面。这样做的好处是即使有些错误的设计预想不周，由于业务的各种原因无时间重构，也可以通过扩展、迁移的方式来降低单点造成的影响程度，然后后期再慢慢优化。