如何选择正确的存储引擎

在大多数情况下，选择innodb 存储引擎是正确的，除非要使用到一些innodb不具备的特性，并且没有其他方法替代的时候，我们才会去选择其他存储引擎。
对于使用其他存储引擎进行存储的情况，可以参考以下几个因素

事务

首先我们需要考虑我们的应用场景是否需要事务。如果应用需要事务支持，Innodb目前是最稳定，并且经过验证的支持事务的存储引擎。

如果不使用事务，主要进行一些读取和插入操作，那么MyISAM也可以进行使用。如果进一步来说，如果表中的数据只会用到insert，连select操作都很少的话，那么也可以采用Archive这种存储引擎。比如大多数日志型的应用，就比较符合这种特性。

备份

另外要参考的因素就是备份。备份也会影响到我们对于存储引擎的选择。 如果可以定期的关闭服务器进行备份的话，那么备份因素可以忽略。但是在生产环境中，数据库服务器一般是不能进行关闭的，那么我们一般就选择可以在线热备的存储引擎。

在前面所说的存储引擎中，只有Innodb有免费的在线热备方案。其他的存储引擎，要么不能在线热备，要么只能有收费的方案。

另外提一下，对于MySQL dump这种备份方式，并不能算是在线热备。一方面MySQL dump进行的是逻辑备份；另一方面，MySQL dump为了保证数据的一致性，必须要为备份的数据加锁。所以说他不是一种在线热备的方案。

崩溃恢复

崩溃恢复也是我们在选择存储引擎时要考虑的一个因素。当数据量比较大的时候，系统崩溃如何能快速的进行恢复，也是一个需要考虑的问题 。相对而言，MyISAM崩溃后发生损坏的概率要比Innodb高很多，而且恢复速度也要更慢。 很多时候，即使不需要事务支持，也要选择Innodb存储引擎。

存储引擎特有特性

最后就要考虑以下存储引擎特有的特性。有些应用场景，就依赖于存储引擎特有的一些特性。有些应用依赖B-tree 索引进行优化，那么就要选择Innodb存储引擎。有些应用要使用到地理空间搜索，如果我们用的是MySQL5.7之前的版本，也只能使用MyISAM存储引擎。如果是使用的MySQL 5.7以后的版本，那么还是应该使用Innodb存储引擎。在MySQL5.7以后的版本，InnoDB已经支持对于地理空间的搜索相关函数的应用了。

不要混合使用存储引擎

在选择存储引擎这个问题上，还有一点需要注意的是，除非万不得已，否则不要混合使用多种存储引擎。可能会带来一些潜在的问题。比如同时使用MyISAM存储引擎和InnoDB存储引擎，一旦在事务中对两种存储引擎的表进行操作，如果这个事务出现了回滚，那么只要InnoDB存储引擎的表才可以进行回滚的。MyISAM存储引擎表中的数据是无法回滚的。这样就会带来一些数据逻辑上的问题。即使不考虑事务的因素，混合使用两种存储引擎，也无法实现完全的在线数据热备。有时呢MyISAM表会带来大量的阻塞，对于性能产生比较大的影响。还是建议不要混合使用存储引擎