这么多存储引擎，我们怎么选择？大部分情况下， InnoDB 都是正确的选择，所以Oracle在MySQL 5.5 版本时终于将InnoDB 作为默认的存储引擎了。对于如何选择存储引擎，可以简单地归纳为一句话：“除非需要用到某些InnoDB 不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB 引擎＂。例如，如果要用到全文索引，建议优先考虑InnoDB 加上Sphinx 的组合，而不是使用支持全文索引的MyISAM 。当然，如果不需要用到InnoDB 的特性，同时其他引擎的特性能够更好地满足需求，也可以考虑一下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对InnoDB 的空间占用过多比较敏感，这种场合下选择MylSAM 就比较合适。
    除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列复杂的问题，以及一些潜在的bug 和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用
    说混合多个存储引擎了。至少，混合存储对一致性备份和服务器参数配置都带来了一些困难。
    如果应用需要不同的存储引擎，请先考虑以下几个因素。

    1. 事务：如果应用需要事务支持，那么InnoDB （或者XtraDB) 是目前最稳定并且经过验证的选择。如果不需要事务，并且主要是SELECT 和INSERT 操作，那么MyISAM 是不错的选择。一般日志型的应用比较符合这一特性。
    2. 备份：备份的需求也会影响存储引擎的选择。如果可以定期地关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB 就是基本的要求。
    3. 崩溃恢复：数据量比较大的时候，系统崩溃后如何快速地恢复是一个需要考虑的问题。相对而言，MylSAM 崩溃后发生损坏的概率比InnoDB 要高很多，而且恢复速度也要慢。因此，即使不需要事务支持，很多人也选择InnoDB 引擎，这是一个非常重要的因素。
    4. 特有的特性：最后，有些应用可能依赖一些存储引擎所独有的特性或者优化，比如很多应用依赖聚簇索引的优化。另外， MySQL 中也只有MyISAM 支持地理空间搜索。如果一个存储引擎拥有一些关键的特性，同时却又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性，有时候通过变通也可以满足需求。

    如果无法确定，那么就使用InnoDB, 这个默认选项是安全的，尤其是搞不清楚具体需要什么的时候。