辛星解读mysql中的MyISAM引擎_MySQL

很多以前的教科书上都是写的MyISAM是mysql的默认存储引擎，其实自从mysql5.5开始，默认存储引擎就已经改变成为InnoDB了，由于InnoDB在很多方面有着不可替代的功能，因此，很多人喜欢研究InnoDB也在情理之中，我也很喜欢InnoDB。但是呢，对于MyISAM，就跟着辛星辛博士来认识一下吧。

第一点就是MyISAM不支持事务和外键，也正是基于这一点，很多人不喜欢MyISAM。但是MyISAM并不着急改变自己，因为这个引擎的重心是性能，而不是功能，不可否认，MyISAM的性能是非常卓越的，尤其在读数据上面。

第二点就是它的文件格式，一个MyISAM表通常分为三部分，第一部分是xxx.frm，这个文件用于存储表的定义，我们使用alter table的时候就会修改这个数据，因此使用alter table的速度是比较快的，第二部分是后缀名是myd的文件，其实这里的d是data的首字母，用于存放MyISAM的数据文件，第三部分是后缀名是myi的文件，这里的i是index的首字母，用于存放MyISAM的索引文件。默认情况下数据文件和索引文件是放在同一个目录下的，但是我们也可以放在不同的目录来获得更高的速度。

第三点就是MyISAM支持三种不同的存储格式，它们分别是静态格式、动态格式和压缩格式，这里注意压缩格式只能使用myisampack工具来创建。先说静态格式，它也是MyISAM的默认存储格式，当我们的表中不包含变量长度列比如varchar等数据类型时，它会自动使用这个格式，每一行都会选用固定的字节数存储。静态格式的优点就是查找速度非常快，容易缓存，容易修复(我在前面讲数据碎片的时候提到过用optimize table来修复表)，缺点就是占据的磁盘空间要多一些。然后说动态格式，动态格式较为复杂一些，因为每行都有一个表明行有多长的列。每个记录仅仅需要必需大小的空间，如果一个记录变大的话，它就按照需要被分开成为多片，造成记录碎片。比如当我们用扩展长度的信息更新数据，该行就会产生碎片。因为动态的原因，也就更容易产生碎片，所以我们往往需要多次的优化表。

       对于压缩表，我们应该先建立一个表，然后使用myisampack来压缩，压缩之后的表会占用较小的磁盘空间，这样会最小化磁盘的使用，而且它是每个记录单独压缩的，所以访问的时候的开销还是蛮小的，它还会修改相应的我们的数据类型。比如一个列的值在-128到127之间，但是我们使用了int来存储，那么它会自动转化为tinyint来存储。如果一个列只有一组很小的可能的值，则列的类型被转化为ENUM。

那么很多人可能想说我们实例操作一下表的压缩吧，好的，辛星童鞋绝对满足大家的要求，我们来实例操作一下，不过必须说明的是，对于太小的表，是不会去压缩的，比如下面的两个例子：

C:\Users\Administrator>myisampack user.MYI
user.MYI is too small to compress

C:\Users\Administrator>myisampack db.MYI
db.MYI is too small to compress

那我们找个稍微大一点的表来做实验：

C:\Users\Administrator>myisampack help_keyword.MYI
Compressing help_keyword.MYD: (483 records)
- Calculating statistics
- Compressing file
95.15%
Remember to run myisamchk -rq on compressed tables

此时，表的压缩就完成了，可以看出我们的表中原来存放了483条记录，而且它还提示我们使用myisamchm来解压缩。

第四点问题就是锁定和并发，MyISAM在加锁的时候会对整张表都加锁，这也是MyISAM广为诟病的一点，但是在处理并发上，在读取数据的时候，所有的表上都可以获得共享锁，也就是每个连接会互不干扰，而在写数据的时候，会获得排他锁，会对整个表进行加锁，其他的请求包括读和写都必须处于等待状态。

第五点就提到了表的修复，这一点也是MyISAM的方便的地方，它可以使用【check table 表名】来检测表，还可以使用【repair table 表名】来修复表，当然还可以使用optimize来优化表，比如去除数据碎片等等。

第六点也是比较重要的一点，那就是，MyISAM是支持全文索引的，但是InnoDB不支持，这也是MyISAM少数的几个比InnoDB功能还多的功能，但是目前的MyISAM貌似还是不支持中文，不过我们可以使用第三方技术来弥补这一点。

这一次就先写到这里吧，期待您的关注。