mysql怎么选存储引擎_MySql存储引擎介绍，如何选择合适的引擎

引言

本博客知知识概要的描述存储引擎，不会涉及太多细节，因为存储引擎相关特知识点太多，特性和细节需要仔细研究，如果感兴趣可以阅读相关官方文档。

像官方文档中提到的存储引擎是从MySql架构开始描述的，存储引擎处于MySql架构最底层实现。

本博客中只介绍主流引擎MyISAM和InnoDB。

一、引擎罗列

目前各大博客中记录最多的就是大家常见的主流的两大引擎MyISAM和InnoDB,其实存储引擎是有很多的，在这里简单罗列了解即可。Blackhole、CSV、Federated、Memory、Merge、NDB、以及其他第三方的引擎。

二、存储引擎InnoDB

InnoDB是MySql默认的事务行存储引擎，也是目前使用最广泛的引擎。拥有主流业务的支持特点，如短期内的事务提交和少量的回滚，本身的性能优化和自动崩溃恢复。除非有特别的需求要使用其他引擎，否则应该优先考虑InnoDB。

InnoDB的数据存储在表空间中，表空间是由InnoDB管理的一个黑盒子，有一系列复杂数据文件组成的。而在MySql4.1版本以后支持了将每个表和索引单独分开放在文件中。

InnoDB采用了MVCC来支持高并发，情妾实现了四个标准的隔离级别，默认的是PEPEATABLE READ可重复读，并通过间隙锁防止幻读的出现，而间隙锁使得InnoDB不仅仅会锁定涉及的行，还会对索引中的间隙行进行锁定，以防止幻影行出现。

InnoDB表是基于聚簇索引建立的，详细请阅读相关文档。聚簇索引对主键查询有很高的性能，不过他的二级索引和非主键索引中必须包含主键列，这就使得主键列很大的话他的其他索引都会很大，应当避免这种情况。

InnoDB内部也做了很多优化，包括从磁盘读取数据时采用的可预测性预读，在写操作时的加速插入进行先插入缓冲区的操纵。

三、存储引擎MyISAM

在MySql5.1之前的版本MyISAM是默认的存储引擎，它提供了大量的特性，包括全文检索，压缩等，但是它和InnoDB比起来不支持事务和行锁，而它最大的缺陷就是奔溃后无法安全回复数据，若对于只读数据，表比较小，可以接受崩溃恢复问题可继续使用MyISAM。

MyISAM会将表存储在两个文件中，数据文件和索引文件，分别以.MYD和.MYI结尾。

MyISAM会对整张表加锁，而不是针对行锁，读取时会对所读到的所有表加共享锁，对写入时则对涉及的表加排他锁，所以很明确，在读共享锁时可以写数据，反之不行。

MyISAM的性能上是比InnoDB高的，这一点很好理解，除了简单的设计以外，还有减少了事务和行锁的所带来的额外服务器开支，但影响MyISAM的罪魁祸首还是表锁问题，若所有查询长期处于Locked状态，那么毫无疑问就是表锁的问题。

MyISAM支持全文检索，这是一种基于分词创建的功能，可以支持复杂查询。

四、选择合适的存储引擎

目前MySql默认的存储引擎时InooDB,并且此存储引擎满足所有必要需求，但是根据业务和数据选择更好的存储引擎也可以提高效率。这么多存储引擎我们怎么选择呢？大部分情况下InnoDB是正确的选择。

对于存储引擎的选择简单的归纳为一句话：除非需要用到某些InnoDB不具备的特性，并且没有其他办法代替，否则都应该选择InnoDB引擎。

例如，我们用到MyISAM的全文检索功能，应当优先选择InnoDB搭配Sphinx组合使用，而不是直接使用MyISAM。

如果用不到InnoDB特性，同时其他存储引擎可以更好地满足需求，也可以考虑一下其他存储引擎。

例如，我们不在乎并发和扩展能力了，也不在乎崩溃数据恢复了，而且嫌弃InnoDB数据文件占用空间了，那么可以选择MyISAM。

另外不到万不得已，不推荐使用混合引擎，它们会带来一些潜在bug，本身在存储引擎和服务器之间的交互已经比较复杂了。

如果应用需要不同的存储引擎，可以考虑一下几个因素

事务

如果应用需要支持事务，那么应该直接使用InnoDB,它是目前最稳定并且经过验证的选择，如果不需要事务，并且是select和insert操作，那么MyISAM是不错的选择。

备份

若你需要热备份那么选择InnoDB是基本的要求。

崩溃恢复

数据量比较大的时候，系统崩溃后如何快速的恢复数据是一个值得考虑的问题，相对而言，MyISAM崩溃后发生损坏的概率比InnoDB要高很多，而且恢复速度很慢，即使不需要事务InnoDB也是大多数人的选择。

特有的特性

有些时候应用可能以来一些存储引擎，因为它们有些独有的特性，如果你需要用的一些特殊的特性，当时有缺乏一些必要的特性时，那么不得不做一个折中的选择了，更或者在架构上做出一些取舍。因为编程是灵活的，引擎无法完成的需求业务也的变通有时可以满足。

五、其他结论

一些常见的场景

只读或者大部分情况下只读的表

例如一些类目和数据罗列的数据表中，只存在select和insert，典型的读多写少场景，也不介意MyISAM的崩溃恢复问题，那么可以选择MyISAM。不要低估恢复数据的重要性，因为MyISAM不会保证将数据安全的全部写到磁盘上，它只是把数据写到内存中，然后等待操作系统定时定期将数据刷出到磁盘上。

订单处理

如果涉及到订单应用，建议采用InnoDB，因为业务上支持事务成了必须的，另外就是考虑对外间的支持和表设计。

其他结论

不要轻易相信MyISAM比InnoDB快的经验之谈，这个结论不是绝对的。

在已知的场景中InnoDB的速度都让MyISAM望尘莫及，尤其是使用到聚簇索引等。如数据量大小，io请求量，主键和二级索引等。某些场景下在使用MyISAM引擎一开始没有任何问题，随着数据量增大，访问压力增大会迅速恶化，开始出现锁争用，锁等待，死锁最后崩溃引发的数据恢复。

以上大部分结论摘自 --MySql高级性能