MySQL中如何选择合适的存储引擎
2018-01-02| 程成| 1040| 0| MySQL

一、存储引擎有哪些


Mysql除了MyISAM和InnoDB存储引擎,还有很多其他的内建存储引擎。


Mysql从2007年开始提供了插件式的存储引擎API,从此涌出了一系列为不同目的而设计的存储引擎。其中有一些已经合并到Mysql服务器,但大多数还是第三方产品或者开源项目。




二、如何选择合适的Mysql存储引擎


这么多的存储引擎,我们怎么选择?大部分情况下,InnoDB都是正确的选择,所以Oracle在MySQL 5.5 版本时终于将 InnoDB 作为默认的存储引擎了。对于如何选择存储引擎,可以简单地归纳为一句话:“除非需要用到某些 InnoDB 不具备的特性,并且没有其他办法可以替代,否则都应该优先选择 InnoDB 引擎”。例如,如果要用到全文索引,建议优先考虑 InnoDB 加上 Sphinx 的组合,而不是使用支持全文索引的 MyISAM。当然,如果不需要用到 InnoDB 的特性,同时其他引擎的特性能够更好地满足需求,也可以考虑一下其他存储引擎。举个例子,如果不在乎扩展能力和并发能力,也不在乎崩溃后的数据丢失问题,却对InnoDB的空间占用过多比较敏感,这种情况下选择MyISAM就比较合适。


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


如果应用需要不同的存储引擎,请先考虑以下价格因素。


事务

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


备份

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


崩溃恢复

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


稀有的特性

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



注:

不要轻易相信“MyISAM 比 InnoDB 快”之类的经验之谈,这个结论往往不是绝对的。在很多我们已知的场景中,InnoDB 的速度都可以让 MyISAM 望尘莫及,尤其是使用到聚簇索引,或者需要访问的数据都可以放入内存的应用。


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




×
作者:程成
QQ:492245711