Mysql 应该选择什么引擎

　　对于如何选择存储引擎，可以简答的归纳为一句话：“除非需要用到某些INNODB 不具备的特性，并且没有其他办法可以替代，否则都应该选择INNODB 引擎”。例如：如果要用到全文索引，建议优先考虑INNODB加上Sphinx的组合，而不是使用支持全文索引的myisam。当然，如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好的满足需求，也可以考虑一下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对InnoDB的空间占用比较敏感，这种场合下选择MyISAM就比较合适。

　　除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列负责的问题，以及一些潜在的bug和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。至少，混合存储引擎对一致性备份和服务器参数配置都带来了一定的困难。

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

　　事务

　　　　如果应用中需要事务支持，那么InnoDB（或者XtraDB）是目前最稳定，并且经验证的选择。如果不需要事务，并且主要是SELECT 和 INSERT 操作，那么myisam是不错　　的选择。一般日志型的应用比较符合这一特性。

　　备份

　　　　备份的需求也会影响到存储引擎的选择。如果可以定期的关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要　　　求。

　　崩溃恢复

　　　　数据量比较大的时候，系统崩溃后如何快速的恢复是一个需要考虑的问题。相对而言，Myisam 崩溃后发生损坏的概论比INNODB 要高很多，而且恢复速度也很慢。因此，　　即使不需要事务支持，很多人也选择INNODB 引擎，这也是一个非常重要的因素。

　　特有的特性

　　　　最后，有些应用可能依赖一些存储引擎独有的特性或者优化，比如很多应用依赖聚簇索引的优化。另外mysql 中也只有myisam 支持地理空间搜索。如果一个存储引擎拥有　　一些关键的特性，同时又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性，有时候通过变通也可以满足需求。

Mysql 应该选择什么引擎

标签：