MySQL存储引擎选型

1、MySQL的存储引擎

完整的引擎说明仍是看官方文档：http://dev.mysql.com/doc/refman/5.6/en/storage-engines.html

这里介绍一些主要的引擎

 

一、InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短时间(short-lived)事务。除非有很是特别的缘由须要使用其余的存储引擎，不然应该优先考虑InnoDB引擎。

建议使用MySQL5.5及之后的版本，由于这个版本及之后的版本的InnoDB引擎性能更好。

MySQL4.1之后的版本中，InnoDB能够将每一个表的数据和索引存放在单独的文件中。这样在复制备份崩溃恢复等操做中有明显优点。能够经过在my.cnf中增长innodb_file_per_table来开启这个功能。以下：

[mysqld]
innodb_file_per_table

 

InnoDB采用MVCC来支持高并发，而且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ(可重复读)，而且经过间隙锁(next-key locking)策略防止幻读的出现。(事务和事务隔离级别是另外一个大题目，各自网补吧)。

 

InnoDB是基于聚簇索引创建的，聚簇索引对主键查询有很高的性能。不过它的二级索引(secondary index，非主键索引)中必须包含主键列，因此若是主键列很大的话，其余的全部索引都会很大。所以表上的索引较多的话，主键应当尽量的小。

 

InnoDB的存储格式是平台独立的，能够将数据和索引文件从Intel平台复制到Sun SPARC平台或其余平台。

 

InnoDB经过一些机制和工具支持真正的热备份，MySQL的其余存储引擎不支持热备份。

 

二、MyISAM存储引擎

MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM不支持事务和行级锁，有一个毫无疑问的缺陷就是崩溃后没法安全恢复。

 

MyISAM会将表存储在两个文件在中：数据文件和索引文件，分别是.MYD和.MYI为扩展名。

在MySQL5.0之前，只能处理4G的数据，5.0中能够处理256T的数据。

 

在数据再也不进行修改操做时，能够对MyISAM表进行压缩，压缩后能够提升读能力，缘由是减小了磁盘I/O。

 

三、Archive引擎

Archive存储引擎只支持INSERT和SELECT操做，在MySQL5.1以前不支持索引。

Archive表适合日志和数据采集类应用。

Archive引擎支持行级锁和专用的缓存区，因此能够实现高并发的插入，但它不是一个事物型的引擎，而是一个针对高速插入和压缩作了优化的简单引擎。

 

四、Blackhole引擎

Blackhole引擎没有实现任何存储机制，它会丢弃全部插入的数据，不作任何保存。但服务器会记录Blackhole表的日志，因此能够用于复制数据到备库，或者简单地记录到日志。但这种应用方式会碰到不少问题，所以并不推荐。

 

五、CSV引擎

CSV引擎能够将普通的SCV文件做为MySQL的表来处理，但不支持索引。

CSV引擎能够做为一种数据交换的机制，很是有用。

 

六、Federated引擎

Federated引擎是访问其余MySQL服务器的一个代理，尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也常常带来问题，所以默认是禁用的。

 

七、Memory引擎

若是须要快速地访问数据，而且这些数据不会被修改，重启之后丢失也没有关系，那么使用Memory表是很是有用。Memory表至少比MyISAM表要快一个数量级。

Memory表是表级锁，所以并发写入的性能较低。它不支持BLOB或TEXT类型的列，而且每行的长度是固定的，这可能呆滞部份内存的浪费。

临时表和Memory表不是一回事。临时表是指使用CREATE TEMPORARY TABLE语句建立的表，它可使用任何存储引擎，只在单个链接中可见，当链接断开时，临时表也将不复存在。

 

八、NDB集群引擎

MySQL服务器、NDB集群存储引擎，以及分布式的、share-nothing的、容灾的、高可用的NDB数据库的组合，被称为MySQL集群(MySQL Cluster)。

 

其余第三方或社区引擎

XtraDB：是InnoDB的一个改进版本，能够做为InnoDB的一个完美的替代产品。

TokuDB：使用了一种新的叫作分形树(Fractal Trees)的索引数据结构。

Infobright：是最有名的面向列的存储引擎。

Groonga：是一款全文索引引擎。

OQGraph：该引擎由Open Query研发，支持图操做(好比查找两点之间的最短路径)。

Q4M：该引擎在MySQL内部实现了队列操做。

SphinxSE：该引擎为Sphinx全文索引搜索服务器提供了SQL接口。

 

2、选择合适的引擎

大部分状况下，InnoDB都是正确的选择，能够简单地概括为一句话“除非须要用到某些InnoDB不具有的特性，而且没有其余办法能够替代，不然都应该优先选择InnoDB引擎”。

除非万不得已，不然建议不要混合使用多种存储引擎，不然可能带来一系列负责的问题，以及一些潜在的bug和边界问题。

若是应用须要不一样的存储引擎，请先考虑如下几个因素：

事务：

    若是应用须要事务支持，那么InnoDB(或者XtraDB)是目前最稳定而且通过验证的选择。

备份：

    若是能够按期地关闭服务器来执行备份，那么备份的因素能够忽略。反之，若是须要在线热备份，那么选择InnoDB就是基本的要求。

崩溃恢复

    MyISAM崩溃后发生损坏的几率比InnoDB要高不少，并且恢复速度也要慢。

特有的特性

    若是一个存储引擎拥有一些关键的特性，同时却又缺少一些必要的特性，那么有时候不得不作折中的考虑，或者在架构设计上作一些取舍。

 

有些查询SQL在不一样的引擎上表现不一样。比较典型的是：

SELECT COUNT(*) FROM table;

对于MyISAM确实会很快，但其余的可能都不行。

 

3、应用举例

 

一、日志型应用

MyISAM或者Archive存储引擎对这类应用比较合适，由于他们开销低，并且插入速度很是快。

若是须要对记录的日志作分析报表，生成报表的SQL极可能会致使插入效率明显下降，这时候该怎么办？

一种解决方法，是利用MySQL内置的复制方案将数据复制一份到备库，而后在备库上执行比较消耗时间和CPU的查询。固然也能够在系统负载较低的时候执行报表查询操做，但应用在不断变化，若是依赖这个策略可能之后会致使问题。

另外一种方法，在日志记录表的名字中包含年和月的信息，这样能够在已经没有插入操做的历史表上作频繁的查询操做，而不会干扰到最新的当前表上的插入操做。

 

二、只读或者大部分状况下只读的表

有些表的数据用于编制类目或者分列清单（如工做岗位），这种应用场景是典型的读多写少的业务。若是不介意MyISAM的崩溃恢复问题，选用MyISAM引擎是合适的。（MyISAM只将数据写到内存中，而后等待操做系统按期将数据刷出到磁盘上）

 

三、订单处理

涉及订单处理，支持事务是必要的，InnoDB是订单处理类应用的最佳选择。

 

四、大数据量

若是数据增加到10TB以上的级别，可能须要创建数据仓库。Infobright是MySQL数据仓库最成功的方案。也有一些大数据库不适合Infobright，却可能适合TokuDB。

 

来源：http://toplchx.iteye.com/blog/1941415