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/ ,谢谢合作