Mysql 应该选择什么引擎_MySQL

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

 

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

 

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

 

事务

 

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

 

备份

 

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

 

崩溃恢复

 

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

 

特有的特性

 

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

 

你不需要现在就做决定，本系列接下来会提供很多关于各种存储引擎优缺点的详细描述，也会讨论一些架构设计的技巧。一般来说，可能有很多选项你还没有意识到，等阅读完本系列回头再看这些问题可能有些帮助。如果无法确定，那么就使用InnoDB ，这个默认选择是最安全的，尤其是搞不清楚具体要什么的时候。

 

日志型应用如何选择引擎

 

假如你需要实时地记录一台中心电话交换机的每一通电话日志到mysql中，或者通过Apache的mod_log_sql 模块将网站的所有访问信息直接记录到表中。这一类应用的插入速度有很高的要求，数据库不能成为瓶颈，MYISAM或者Archive存储引擎对这类应用比较适合，因为他们成本开销低，而且插入速度非常快。

 

如果需要对记录的日志做分析报表，则事情就会变得有趣 了。生成报表的sql很有可能会导致插入效率降低，这时候怎么办？

 

一种解决方法：是利用mysql内置的复制方案将数据复制一份到备份库，然后在备份库执行比较好事和cpu的查询。这样主库只用于高效的插入工作，而备份库上执行的查询也无需担心影响到日志的插入性能。当然也可以在系统负载较低的时候执行报表查询操作，但是应用在不断变化，如果依赖这个策略可能以后会导致问题。

 

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

 

只读或者大部分情况下只读的表

 

有些表的数据用于编制类目或者分裂清单（如工作岗位，竞拍，不动产等）这些应用场景是典型的读多写少的业务。如果不介意MyISAM 的崩溃恢复问题，选择MyISAM 引擎是合适的。不过不要低估崩溃恢复问题的重要性，有些存储引擎不会保证将数据安全的写入磁盘中，而许多用户实际上并不清楚这样有多大的风险（MyISAM 只将数据写到内存中，然后等待操作系统定期的将数据刷出到磁盘上）。

 

tips：一个值得推荐的方式，是在心梗测试环境模拟真实环境，运行应用，然后拔下电源模拟崩溃测试。对崩溃恢复的第一手测试经验是无价之宝，可以避免真的崩溃时手足无措。

 

不要轻易相信 ‘MYISAM 比 INNODB 快’之类的经验之谈，这个结论往往不是绝对的。在很多我们已知的场景中，INNODB 的数度都可以让MYISAM 望尘莫及，尤其是用到聚簇索引，或者需要访问的数据都可以放入内存的应用。在后面的章节，读者可以了解更多影响存储引擎性能的因素（如数据大小，io请求量，主键还是二级索引等）以及这些因素对应用的影响。

 

当设计上述类型的应用时，建议蚕蛹InnoDB 。MyISAM 引擎在一开始可能没有任何问题，但是随着应用压力的上升，则可能迅速恶化。各种锁征用、崩溃后的数据丢失问题都会随之而来。

 

订单处理

 

如果设计订单处理，那么支持事务就必须选择。半完成的订单无法吸引应用的用户。另外一个重要的考虑点是存储引擎对外键的支持情况。InnoDB 是订单处理类应用的最佳选择。

 

电子公告牌和主题讨论论坛

 

对于mysql 的用户，主题讨论区是个很有意思的话题。当前有成百上千的基于php或者perl的免费系统可以支持主题讨论。其中大部分的数据库操作效率都不高，因为他们大多倾向于在一次请求中执行尽可能多的查询语句。另外还有部分系统设计为不采用数据库，当然也就无法利用到数据库提供的一些方便特性。主题讨论区一般都有更新计数器，并且为给个主题计算访问统计信息。多数应用只设计了几张表来保存所有的数据，所以核心表的读写压力可能非常大。为保证这些核心表的数据一致性，锁成为资源竞争的主要因素。

 

尽管有这些设计缺陷，但大多数应用在低负载时可以工作的很好。如果web站点的规模迅速扩展，流量随之猛增，则数据库访问可能变得非常慢。此时一个典型的解决方案是更改为支持更高读写的存储引擎，但有时用户会发现这么做反而导致系统变得更慢了。

 

用户可能没有意识到这是由于某些特殊的查询的缘故，典型的如：

 

SELECT COUNT(*) FROM table

 

 问题在于，不是所有的存储引擎运行上述查询都非常快：对于MYISAM 确实会非常快，但其他的可能不行。每种引擎都能找出类似和对自己有利的例子。下一章将帮助用户分析这些情况，演示如何发现和解决存在的这类问题。

 

CD-ROM应用

 

如果要发布一个基于CD-ROM或者DVD-ROM并且使用mysql数据文件的应用，可以考虑使用MYISAM或者MYISAM压缩表，这样表之间可以隔离，兵器可以在不同介质上相互拷贝。MYISAM压缩表比未压缩表要节约很多空间，但压缩表是只读的。在某些应用中这可能是很大的问题。但如果数据放到只读戒指的场景下，压缩表的只读特性就不是问题了，这就没有理由不使用压缩表了。

 

大数据量

 

什么样的数据量算大？我们创建或者管理很多INNODB 数据库的数据量在3-5tb之间，或者更大，这是单台机器上的量，而不是一个分片（shard）的量。这些系统运行得还不错，要做到这一点需要合理的选择硬件，做好物理设计，并为服务器的io瓶颈做好规划。在这样的数据量下，如果采用myisam，崩溃后的恢复就是一个噩梦。

 

如果数据量持续增长到10tb以上级别，可能就要建立数据仓库。Infobright，是myslq数据仓库最成功的解决方案。也有一些大数据库不适合Infobright，却可能适合TokuDB.