MySQL中MyISAM引擎及InnoDB引擎的缓存优化设计

MyISAM引擎中，为了提升io效率以及读取效率，将对磁盘频繁读取的索引数据加载至内存中操做。

MyISAM设计了一个在存放在内存中的索引缓冲池Key Cache。Key Cache只缓存索引数据，经过LRU算法将读取频繁的索引加载到Key Cache中来。

经过系统变量 key_buffer_size 来控制Key Cache的大小，这个变量关乎到缓存的性能。

 

InnoDB引擎中，一样设置了缓存池buffer pool，与MyISAM有所区别的是，buffer pool不单单缓存了索引数据，同时还缓存了表数据。

这样的缓冲池同时也带来了不少问题：缓存中的数据如何与磁盘上的数据保持一致，缓存中的数据支不支持修改更新操做，以及与日志记录模块的同步等等问题。

要解决这些问题带来的操做时繁琐的，可是相比于总体性能的提高，也是值得的：硬盘的存取速度与内存的速度更本不是一个数量级的，经过内存来读取数据，能够大大的提升数据库的总体性能。

MySQL官方文档这样建议，除了用于系统运行的内存外，剩余的内存建议尽量大的设置buffer pool。这样一来有着大容量的buffer pool，在实际应用上的表现更像与一个in-memory database，相比于对磁盘的读写速度，读写性能简直就是巨大的提高。

这一切固然基于读取数据在buffer pool的命中率上面，修改更新等操做会改变buffer pool的一些数据，经过LRU算法更新，将buffer pool的命中率维持在一个比较高的水平。

 

还有一个问题就是怎么将buffer pool中的数据同步到磁盘。想一想若是更新一次buffer pool就写一次磁盘，那这样子的效率和直接读写磁盘并无提升多少，这里就须要设计出同步策略来解决这个问题。

InnoDB是事务安全的，修改buffer pool的数据后，同时还要将此操做记录在事务日志中去。这里对buffer pool的修改操做后，并无直接将数据同步到磁盘，而是将此操做记录到事务日志文件中去。这里又有一个疑问，为何不将数据写到磁盘的表数据文件里去，而是写到磁盘的事务日志文件去呢，一样是磁盘写操做，有何不一样？

这里涉及到磁盘寻道读写问题，学过计算机组成原理的就知道了，磁盘读写能够分为两种：顺序读写以及随机读写，若是为随机读写，将要花必定的时间用于磁头寻址上，若是为顺序读写，则是连续的将数据写入磁面，磁头寻址操做不多。这两种读写方式的效率也可见区别甚大

事务日志文件是InnoDB引擎申请连续物理空间的固定大小的一个文件，对日志文件的读写基本上是顺序读写，寻址操做甚少。

而buffer pool中的表数据多而复杂：多个表的数据文件在磁盘中的存储空间是不一样的，具备随机性，若每次更新buffer pool中的数据到磁盘，每次操做的表空间表现出随机性，对磁盘的读写也是随机的，这样以来频繁的寻址读写操做，将使磁盘处于一个繁忙随机读写状态。

因此buffer pool的策略也使得总体io性能获得了提高。

 

转载请注明出处：http://www.cnblogs.com/iamsupercp/  ,谢谢合做