当前位置:Gxlcms > mysql > Mysql应该选择什么引擎_MySQL

Mysql应该选择什么引擎_MySQL

时间:2021-07-01 10:21:17 帮助过:36人阅读

对于如何选择存储引擎,可以简答的归纳为一句话:“除非需要用到某些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.

人气教程排行