Mysql源代码分析(7): MYISAM的数据文件处理

好久没写分析文章了，一个是比较忙，另一个是因为余下的内容都是硬骨头，需要花时间慢慢理解。剩下的比较有意思的内容有： 

select语句的执行和优化过程。大家关心数据库的查询性能，主要是对着部分比较感兴趣，特别是其中的查询优化部分。 
Mysql的replication。Mysql的master/slave架构是大部分使用mysql的高性能网站架构的不二选择，replication则是这个架构的基础。 
具体数据库引擎的实现。这部分也是很多关心mysql性能的人会比较感兴趣的部分，不过这个工作比较复杂，特别是流行的innodb，这个工作量尤其浩大，而且难度颇高。其中涉及到transaction的部分，也是特别复杂。 

另外，我发现我写的文章被一些地方转摘了，感谢大家的阅读，但是我也希望转摘要注明出处，至少给个原文链接吧，也不枉我幸苦一场。 

今天主要写写Myisam的数据文件的处理。 

Myisam是最早实现的Mysql数据库引擎，也是人们心中的性能最好的引擎（虽然不是功能最强的，没办法，现实往往要求性能和功能做权衡）。这里选择分析它，主要原因是其实现还算比较简单明了，而且最近我对数据文件的格式比较感兴趣，特别是变长数据的处理。要注意的是本文不会介绍myisam的索引文件格式。 

基本知识 
对于每一个以Myisam做数据引擎的表，在<%data_dir%>/<database>目录下会有如下几个文件来保存其相关信息： 

.frm文件。 这个文件是跨引擎的，描述了该表的元信息，其中最重要的是表定义和表的数据库引擎。 
.MYD文件。这是我们要看的重点文件，包含了数据库record信息，就是数据库中的每个行。 
.MYI文件。索引文件，用来加速查找。 

而对于MYD中的每个record，可以是fixed，dynamic以及packed三种类型之一。fixed表示record的大小是固定的，没有VARCHAR, blob之类的东东。dynamic则刚好相反，有变长数据类型。packed类型是通过myisampack处理过的record。参见：http://dev.mysql.com/doc/refman/5.1/en/myisam-table-formats.html。 

需要注意的是record类型是针对表的设置，而不是对每个column的设置。 

record处理接口 
record的类型是表级别的设置，所以在一个表被打开的时候，myisam会检查元数据的选项，看该表的record是什么类型，然后设置对应的处理函数，具体处理在storage/myisam/mi_open.c的mi_setup_functions中，我们看其中的一个片段： 
746 void mi_setup_functions(register MYISAM_SHARE *share) 
747 { 
         .... 
759   else if (share->options & HA_OPTION_PACK_RECORD) 
760   { 
761     share->read_record=_mi_read_dynamic_record; 
762     share->read_rnd=_mi_read_rnd_dynamic_record; 
763     share->delete_record=_mi_delete_dynamic_record; 
764     share->compare_record=_mi_cmp_dynamic_record; 
765     share->compare_unique=_mi_cmp_dynamic_unique; 
766     share->calc_checksum= mi_checksum; 
767 
768     /* add bits used to pack data to pack_reclength for faster allocation */ 
769     share->base.pack_reclength+= share->base.pack_bits; 
770     if (share->base.blobs) 
771     { 
772       share->update_record=_mi_update_blob_record; 
773       share->write_record=_mi_write_blob_record; 
774     } 
775     else 
776     { 
777       share->write_record=_mi_write_dynamic_record; 
778       share->update_record=_mi_update_dynamic_record; 
779     } 
780   } 
         ... 

这是针对pack类型的处理函数设置。设置了share结构中的一堆函数接口。顺便说一句，这种方式是C语言编程中常用的实现”多态“的办法：申明函数接口，动态设置接口实现，思想上和C++的动态绑定是一致的。这段代码对于dynamic类型的表的record处理函数做了设置。比较有趣的是HA_OPTION_PACK_RECORD用来指定dynamic类型。


看到这些函数名大家可以猜想出他们都是干嘛的，下面主要看看fixed类型和dynamic类型的具体处理。 
Fixed类型 
顾名思义，fixed类型的表中的所有字段都是定长的，不能出现TEXT, VARCHAR之类的东东。这种严格限制带来的好处就是更快更直接的数据record操作，想想也知道，每个数据都是定长的，在文件操作的时候多方便啊。 
看看一个数据的函数_mi_write_static_record，它在mi_statrec.c中，所有对于fixed record的操作的实现都定义在这个文件中。 

21 int _mi_write_static_record(MI_INFO *info, const uchar *record) 
22 { 
       ... 
24   if (info->s->state.dellink != HA_OFFSET_ERROR && 
25       !info->append_insert_at_end) 
26   { 
         检查dellink中是否有record。dellink是所有被删除的数据构成的链表。当一个record被删除的时候，它 
所占的文件大小不是被马上释放，而是被放入dellink中，等候下次使用。 
27     my_off_t filepos=info->s->state.dellink; 
         读入dellink所指向的数据空间的信息。 
33     更新dellink，将使用了的数据空间移除。 

         将record写入找到的已删除的数据的空间中。 

40   } 

41   else 
42   { 
43     检查数据文件是否过大。 
49     如果使用的写缓冲，则写入写缓冲。 
         将新数据写入文件最后。 
         更新元数据。 
         ... 
86 } 



因为所有的数据都是一样大小，处理起来很简单。特别是当一个数据被删除的时候，它所占的空间被放入一个回收链表中，下次要写入新数据的时候，如果回收链表不为空，直接从其中找一个写入新数据即可，不用分配新的存储空间。 

Fixed类型的其他处理也都很简单，这里不再多说了。需要提出的是，不管用的什么类型的数据，当数据被删除的时候，其所占的空间并不是马上被释放的，那样操作代价太大，要把该数据后面的所有数据向前移位，肯定无法忍受。一般的做法都是将这些空间用链表穿起来，供以后使用，所以数据文件一般是不会主动缩小的.....即使是innodb也是这样。 

Dynamic类型 
Dynamic类型是相对于fixed的类型而言，这种类型可以容忍变长数据类型的存在。随之而来的是更复杂的数据文件的操作。Dynamic类型中被删除的数据块也不是马上被释放，也被链表连起来。下次要写入新数据的时候，还是优先从这个链表中找。不同于fixed类型的处理在于新来的数据和链表中的空间的大小可能不一样。如果新数据大了，就会找好几个空余空间，将数据分散于多个数据块中，如果新数据小了，则会将空余数据块分成两个，一个写入新数据，一个还是放在空余链表中供后来者使用。 

看一下mi_dynrec.c中的write_dynamic_record函数。 
320 static int write_dynamic_record(MI_INFO *info, const uchar *record, 
321         ulong reclength) 
322 { 
         检查是否有足够的空间来存放新数据，空间满了返回错误。 
351 
352   do 
353   { 
          // 找一个可以写入数据的地方。注意这里是在一个循环里面，也就是说每次找到的 
          // 空间不一定能够写入整个数据，只能写入部分的话，剩下的还要继续找地方写。 
354     if (_mi_find_writepos(info,reclength,&filepos,&length)) 
355       goto err; 
          // 写入能够放入找到的空间的数据。 
356     if (_mi_write_part_record(info,filepos,length, 
357                               (info->append_insert_at_end ? 
358                                HA_OFFSET_ERROR : info->s->state.dellink), 
359             (uchar**) &record,&reclength,&flag)) 
360       goto err; 
361   } while (reclength); 
         ... 
      } 
其中的循环说明了一切，很有可能一个数据会被分成几块儿，写到不同的地方，但是他们合起来才构成了整个数据。

再看_mi_find_writepos。 
371 static int _mi_find_writepos(MI_INFO *info, 
372            ulong reclength, /* record length */ 
373            my_off_t *filepos, /* Return file pos */ 
374            ulong *length)   /* length of block at filepos */ 
375 { 
376   MI_BLOCK_INFO block_info; 
         ... 
         // 先检查dellink中是否有空余的空间。 
380   if (info->s->state.dellink != HA_OFFSET_ERROR && 
381       !info->append_insert_at_end) 
382   { 
383     /* Deleted blocks exists;  Get last used block */ 
           存在空余空间，那就把链表中的头找出来，把其中的空间用来写入新数据。 
           将这块空间的描述返回给调用者。 
           .... 
398   } 
399   else 
400   { 
401     /* No deleted blocks;  Allocate a new block */ 
           没有已删除的空间，那就在数据文件的最后分配空间，并返回给调用者。 
421   } 
         ... 
      } 
如果有已删除的空间的话，那就直接把链表头描述的空间返回。这个算法很简单，但是我觉得这样简单的算法可能会赵成一些问题，比如存储的碎片化，一块儿大空间被切的越来越小，到后来写入一个数据要使用好几个空间。这些问题在操作系统的内存管理中也同样存在，所以产生了大量的内存管理算法，这里也应该可以借用吧。 


具体的写入是在_mi_write_part_record中完成的。这个函数比较长，我就直接简写如下了。 
int _mi_write_part_record(MI_INFO *info,                                  
         my_off_t filepos, /* points at empty block */ 
         ulong length,   /* length of block */ 
         my_off_t next_filepos,/* Next empty block */ 
         uchar **record, /* pointer to record ptr */ 
         ulong *reclength, /* length of *record */ 
         int *flag)    /* *flag == 0 if header */ 
{ 
   如果给出的空间空间大于数据长度的话，计算填完数据后剩余的空间。 
   如果空间刚好，准备一些元数据。 
   如果空间太小，则找到下一个写入空间的位置（要么是下一个dellink，要么是文件末尾)，并准备这些元数据。如果是第一部分的数据的话，要写入更多的信息。 
   如果空间太大，有剩余空间的话，先看这个空间能否与和下一个空闲空间连接起来形成一个大空间，如果能的话就合并。将其相关的元数据，比如空间的位置，大小之类的，准备好。 
   开始写数据罗，如果启用了写缓冲，则写入缓冲，否则写入找出来的空间。 
   更新dellink的相关信息。 
}

逻辑很清楚，主要是要处理空间过大或者过小带来的复杂性。 

好了，到了这里大部分的处理都很清楚了，还是很直接的。剩下的就是在删除一个数据的时候，将其所占的空间放到dellink中，要注意的是，如果其数据块可以和dellink中的其他数据块合并，合并操作也是在删除数据的操作中调用的，而且合并出来的数据块还可能和其他数据块继续合并

上文来自：http://blog.csdn.net/saylerboxer/article/details/6989222