mysq果l存储引擎优化.docxVIP

存储引擎优化MyI SAM存储引擎优化我们知道，MyISAM 存储引擎是MySQL 最为古老的存储引擎之一，也是最为流行的存储引擎之一。对于以读请求为主的非事务系统来说，MyISAM 存储引擎由于其优异的性能表现及便利的维护管理方式无疑是大家最优先考虑的对象。我们将通过分析MyISAM 存储引擎的相关特性，来寻找提高MyISAM 存储引擎性能的优化策略。索引缓存优化MyISAM 存储引擎的缓存策略是其和很多其他数据库乃至MySQL 数据库的很多其他存储引擎不太一样的最大特性。因为他仅仅缓存索引数据，并不会缓存实际的表数据信息到内存中，而是将这一工作交给了OS 级别的文件系统缓存。所以，在数据库优化中非常重要的优化环节之一“缓存优化”的工作在使用MyISAM 存储引擎的数据库的情况下，就完全集中在对索引缓存的优化上面了。在分析优化索引缓存策略之前，我们先大概了解一下MyISAM 存储引擎的索引实现机制以及索引文件的存放格式。MyISAM 存储引擎的索引和数据是分开存放于“.MYI”文件中，每个“.MYI”文件由文件头和实际的索引数据。“.MYI”的文件头中主要存放四部分信息，分别称为：state（主要是整个索引文件的基本信息），base（各个索引的相关信息，主要是索引的限制信息）， keydef（每个索引的定义信息）和recinfo（每个索引记录的相关信息）。在文件头后面紧接着的就是实际的索引数据信息了。索引数据以Block（Page）为最小单位，每个block 中只会存在同一个索引的数据，这主要是基于提高索引的连续读性能的目的。在MySQL 中，索引文件中索引数据的block 被称为Index Block，每个Index Block 的大小并不一定相等。在“.MYI”中，Index Block 的组织形式实际上只是一种逻辑上的，并不是物理意义上的。在物理上，实际上是以File Block 的形式来存放在磁盘上面的。在Key Cache 中缓存的索引信息是以“Cache Block”的形式组织存放的，“Cache Block”是相同大小的，和“.MYI”文件物理存储的Block（ File Block ） 一样。在一条Query 通过索引检索表数据的时候， 首先会检查索引缓存（key_buffer_cache）中是否已经有需要的索引信息，如果没有，则会读取“.MYI”文件，将相应的索引数据读入Key Cache 中的内存空间中，同样也是以Block 形式存放，被称为Cache Block。不过，数据的读入并不是以Index Block 的形式来读入，而是以File Block 的形式来读入的。以File Block 形式读入到Key Cache 之后的Cache Block 实际上是于File Block 完全一样的。如下图所示：当我们从“.MYI”文件中读入File Block 到Key Cache 中Cache Block 时候，如果整个Key Cache中已经没有空闲的Cache Block 可以使用的话，将会通过MySQL 实现的LRU 相关算法将某些Cache Block清除出去，让新进来的File Block 有地方呆。我们先来分析一下与MyISAM 索引缓存相关的几个系统参数和状态参数：◆ key_buffer_size，索引缓存大小；这个参数用来设置整个MySQL 中的常规Key Cache 大小。一般来说，如果我们的MySQL 是运行在32 位平台纸上，此值建议不要超过2GB 大小。如果是运行在64 位平台纸上则不用考虑此限制，但也最好不要超过4GB。◆ key_buffer_block_size，索引缓存中的Cache Block Size；在前面我们已经介绍了，在Key Cache 中的所有数据都是以Cache Block 的形式存在，而key_buffer_block_size 就是设置每个Cache Block 的大小，实际上也同时限定了我们将“.MYI”文件中的Index Block 被读入时候的File Block 的大小。◆ key_cache_division_limit，LRU 链表中的Hot Area 和Warm Area 分界值；实际上，在MySQL 的Key Cache 中所使用的LRU 算法并不像传统的算法一样仅仅只是通过访问频率以及最后访问时间来通过一个唯一的链表实现，而是将其分成了两部分。一部分用来存放使用比较频繁的Hot Cacke Lock（Hot Chain），被成为Hot Area，另外一部分则用来存放使用不是太频繁的Warm Cache Block（Warm Chain），被成为Warm Area。这样做的目的主要是为了保护使用比较频繁的Cache Block 更不容易被