一、常见存储引擎特性
Innodb
具有提交、回滚和崩溃恢复能力的事务安全、支持外键。使用 mvcc 以及行锁来提供事务支持，因此支持高并发。适用于写频繁，并发率高的应用。
Myisam
不支持事务和灾难自动恢复，但其访问速度快，支持全文索引，对事务完整性没有要求。 通常用于读频繁的数据库，如数据仓库等。
Memory
使用存在内存中的内容来创建表，表访问非常得快，因为它的数据是放在内存中的，并且默认使用 HASH 索引。但是一旦服务关闭，表中的数据就会丢失掉。 。适用于临时的，需要频繁读写，对性能速度要求严格的应用中，如一些统计操作的中间结果表
二、选择存储引擎时需要考虑的因素
并发
如果最好的满足你的并发性需求取决你的工作量了。如果你仅仅是并发的插入和读取。不管相信与否 ，MyISAM是最好的了。如果你让这些操作互不干扰，就应该选择一个支持行锁的引擎。某些应用程序比其他应用程序具有很多的颗粒级锁定要求（如行级锁定）。选择正确的锁定策略能够减少开销，并有助于整体性能的提升。它还包括对多种能力的支持，如多版本并发性控制或“快照”读取
事务支持：
并非所有的应用程序都需要事务，但对的确需要事务的应用程序来说，有着定义良好的需求，如ACID兼容等。
备份
有规律的备份也影响表的引擎选择。如果服务器关闭，并且定期的备份，存储引擎很容易处理。如果 你需要在线备份并从一个格式转换为另一个。这个选择就不明智了。以后会详细说这部分。
要考虑多引擎所引起的备份和服务器调整的复杂性。
错误恢复
如果你有很多数据，你要考虑错误恢复的时间。MyISAM相对于InnoDB非常容易崩溃而且从崩溃中恢复的时间非常慢，这就是为什么有的人即使不使用事务处理也要用InnoDB了。
特殊功能
最终，你可能发现有的应用需要依靠一些MySQL存储引擎特殊的功能和优化，举个例子，有的应用程序 非常依赖于集群的索引优化。这时候，你只能在InnoDB和solidDB选择了。另一方面，只有MyISAM支持全 文索引。如果一个存储引擎遇到了一个或多个苛刻的需求，对于其他并不算是，那么你就要选一个折中的 方案或者找到一个好的解决方案。通常你能从看上去不满足你的需求的存储引擎，找到你所需要的。
