在使用数据库设计系统时，采用的是mysql。在实际线上使用的时候，却出现了性能和缓存等方面的问题，研究mysql刻不容缓。然而mysql目前支持好多个存储引擎，到底哪个更适合，还是混合着用呢？我们需要完整的了解各个存储引擎的特性，才能在实际项目中发挥最好的作用。
    下面是摘自【mysql性能调优与架构设计】这本书的关于多个mysql存储引擎的介绍，非常精练而清晰，所以原文保存，备查。

    MyISAM存储引擎是MySQL默认的存储引擎，也是目前MySQL使用非常广泛的存储引擎之一。它的前身就是我们在MySQL发展历程中所提到的ISAM，是ISAM的升级版本。其实在MySQL最开始发行的时候只有ISAM存储引擎，甚至当时的MySQL可以说还没有存储引擎这个概念。早期MySQL的架构中并没有sql layer和storage engine layer这两个结构清晰的层次，当时不管是理解代码还是系统架构，对于开发者来说都很痛苦的一件事情。到后来，MySQL意识到须要更改架构，将前端的业务逻辑和后端数据存储以清晰的层次结构拆分开，同时对ISAM做了功能上面的扩展和代码的重构，这就是MyISAM存储引擎的由来。
    在MySQL 5.1之前（不包括5.1）的版本中，存储引擎必须在MySQL安装的时候和MySQL一起被编译并同时被安装。也就是说，5.1版之前的版本中，虽然存储引擎层和sql层的耦合已经非常少了，基本上完全是通过接口来实现交互的，但是这两层之间仍然没办法分离，即使在安装的时候也是一样。
    但是从MySQL 5.1开始，MySQL AB对其结构体系做了较大的改造，并引入了一个新的概念：插件式存储引擎体系结构。MySQL AB在改造架构的时候，让存储引擎层和SQL层各自更为独立，耦合更小，甚至可以做到在线加载新的存储引擎，也就是完全可以将一个新的存储引擎加载到一个正在运行的MySQL中，且不影响MySQL的正常运行。插件式存储引擎的架构，使得存储引擎的加载和移出更为灵活方便，也使自行开发存储引擎更为方便简单。在这一点上面，目前还没有哪个数据库管理系统能够做到。
    MySQL的插件式存储引擎主要包括MyISAM、InnoDB、NDB Cluster、Maria、Falcon、Memory、Archive、Merge、Federated等，其中最著名而且使用最为广泛的是MyISAM和InnoDB两种存储引擎。MyISAM是MySQL最早的ISAM存储引擎的升级版本，也是MySQL默认的存储引擎。实际上InnoDB并不是MySQL公司的，而是Innobase软件公司（在2005年被Oracle公司所收购）开发的，其最大的特点是提供了事务控制等特性，所以使用者也非常广泛。
    其他一些存储引擎相对来说都应用于某些特定的场合，如NDB Cluster虽然也支持事务，但是主要是用于分布式环境，属于一个share nothing的分布式数据库存储引擎。Maria是MySQL最新开发（还没有发布最终的GA版本）的MyISAM的升级版存储引擎，Falcon是MySQL公司自行研发的替代当前InnoDB存储引擎的一款带有事务等高级特性的数据库存储引擎，目前正在研发阶段。Memory存储引擎的所有数据和索引均存储于内存中，所以主要是用于一些临时表，或者对性能要求极高，但是允许在系统崩溃（crash）的时候丢失数据的特定场合。Archive是一个数据经过高比例压缩存放的存储引擎，主要用于存放过期而且很少访问的历史信息，不支持索引。Merge和Federated在严格意义上来说，并不能算作存储引擎。因为Merge存储引擎主要用于将几个基表中的数据合并（merge）到一起，对外作为一个表来提供服务，基表主要基于MyISAM存储引擎。而Federated所做的事情，实际上有点类似于Oracle的dblink，主要用于远程存取其他MySQL服务器上面的数据。
    我个人的一个使用建议，不一定完全正确：MyISAM一般情况下性能更高，如果不需要事务支持的情况下，选择这个比较好。如果需要事务支持，要选择InnoDB。而如果要是分布式设计，那要选择NDB Cluster。如果是需要实时性特别高，性能要求特别高，比如一个设备的实时状态，对于数据的丢失容忍度很大，可以采用Memory引擎。不过在系统实现的时候，可以做一些处理，不完全依赖数据库的容灾。这样可以充分利用数据库的性能和应用系统程序的容灾。