背景
DB为了提升不同场景下的性能，Cache的使用也非常普遍，PolarDB作为追求性能的数据库，Cache也是非常重要的组成部分。本文主要探讨我们在PolarDB MySQL产品中有哪些Cache，这些Cache又是如何提升数据库的性能的，帮助您匹配自己的场景合理使用Cache，最大化的提升性能。本文主要讲述几种Cache的作用和区别:
从上述Cache的介绍中可以了解Cache的作用，本文简要做介绍，主要分析各种Cache在PolarDB中的位置，以及加速的方式。
PolarDB 架构中的Cache
为了方便读者了解不同Cache的功能，本文介绍PolarDB中的Cache展示在下面架构图中。 
PolarDB的Cache中，本文优先介绍Buffer Pool，它是数据库中最重要最常见的Cache，负责磁盘和内存的交互，数据库中数据页的查询和修改都需要先将数据加载到内存中进行，因此Buffer Pool的Cache命中率对性能至关重要；其次介绍Polarstore的EMP，位于Buffer Pool的下一层，在分布式存储集群中，相比Buffer Pool容量更大，通过优化Buffer Pool未命中时产生的IO延迟来优化DB的性能；然后介绍Query Cache，它是优化查询的Cache，针对特定查询SQL的优化，使用场景较为固定；最后介绍Redo Cache，是PolarDB 一写多读架构特有的优化，RW新增Redo Cache同步到多个RO节点，能够提升Redo同步性能同时降低RO的IO开销。
Buffer Pool
InnoDB中Buffer Pool通常占物理内存的80%以上，用于cache InnoDB中table 和Index的数据，是InnoDB最重要的组件之一。Buffer Pool 负责内存和存储的数据交互，为了提高缓存效率，用LRU链表管理。由于InnoDB中所有的操作都发生在内存中，Buffer Pool的命中率成为MySQL性能调优一个重要方面。
Buffer Pool采用LRU算法的变异方式进行管理，将LRU list从3/8处分为New Sublist 和Old Sublist，新插入的Page放在Old Sublist头部，优先淘汰Old Sublist 尾部的Page，访问链表会使Page更加”Young”，可以将其移到New Sublist 头部，分成两个Sublist的目的是防止Scan请求将Buffer Pool的数据都替换一遍，导致之后的请求访问Cache都失效，降低Buffer Pool命中率，数据库性能降低。
Buffer Pool的算法在很多文档中有更加详细的介绍，这里只做简介，主要介绍PolarDB中为提高Buffer Pool的命中率的优化：Page 逻辑预读。
MySQL官网支持预读的模式都是物理预读，预读的方式是物理连续的空间，会读取一个extent的若干Page，但随着Page的修改，extent碎片化会导致这种预读方式读到很多无效的Page，无法达到预读的目的还会产生无用的I/O，反而影响正常的I/O性能。基于此，PolarDB实现逻辑预读，即针对B+ tree的逻辑进行预读，能够准确的预读需要的Page，从而来提高Buffer Pool的命中率。
