您所在的位置： &
论MySQL数据库中两种数据引擎的差别
论MySQL数据库中两种数据引擎的差别
蟋蟀的草坪
InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，请注意任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。
InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。
基本的差别为：
MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。
MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。
MyIASM是IASM表的新版本，有如下扩展：
二进制层次的可移植性。&
NULL列索引。&
对变长行比ISAM表有更少的碎片。&
支持大文件。
更好的索引压缩。
更好的键吗统计分布。
更好和更快的auto_increment处理。
以下是一些细节和具体实现的差别：
1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like &%aaa%&
任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。
原来链接：/yan5lang/archive//2039499.html
【编辑推荐】
【责任编辑： TEL：（010）】
关于&&的更多文章
MySQL 5.6.10已经发布，Oracle将其称之为MySQL 5.6正式版。51CTO
数据库产品
数据库综合
数据库新闻
维基百科将切换到另外一款开源数据库MariaDB
Oracle数据库的查询优化，是DBA们需要考虑的问题。在
Oracle数据库的配置工作十分复杂，不光涉及到存储数据
Infobright是一个与MySQL集成的开源数据仓库（Data Wa
本书是程序员面试宝典系列中的一册，也是上一本《程序员面试宝典》的姊妹书。本书对程序设计面试中Java常见的题型和常用解答技巧
51CTO旗下网站Mysql 应该选择什么引擎
对于如何选择存储引擎，可以简答的归纳为一句话：&除非需要用到某些INNODB 不具备的特性，并且没有其他办法可以替代，否则都应该选择INNODB 引擎&。例如：如果要用到全文索引，建议优先考虑INNODB加上Sphinx的组合，而不是使用支持全文索引的myisam。当然，如果不需要用到InnoDB的特性，同时其他引擎的特性能够更好的满足需求，也可以考虑一下其他存储引擎。举个例子，如果不在乎可扩展能力和并发能力，也不在乎崩溃后的数据丢失问题，却对InnoDB的空间占用比较敏感，这种场合下选择MyISAM就比较合适。
除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列负责的问题，以及一些潜在的bug和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。至少，混合存储引擎对一致性备份和服务器参数配置都带来了一定的困难。
如果应用需要不同的存储引擎，请先考虑以下几个因素：
如果应用中需要事务支持，那么InnoDB（或者XtraDB）是目前最稳定，并且经验证的选择。如果不需要事务，并且主要是SELECT 和 INSERT 操作，那么myisam是不错的选择。一般日志型的应用比较符合这一特性。
备份的需求也会影响到存储引擎的选择。如果可以定期的关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要求。
数据量比较大的时候，崩溃后如何快速的恢复是一个需要考虑的问题。相对而言，Myisam 崩溃后发生损坏的概论比INNODB 要高很多，而且恢复速度也很慢。因此，即使不需要事务支持，很多人也选择INNODB 引擎，这也是一个非常重要的因素。
特有的特性
最后，有些应用可能依赖一些存储引擎独有的特性或者优化，比如很多应用依赖聚簇索引的优化。另外 中也只有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.
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'mysql数据库引擎：MyISAM和InnoDB
mysql数据库引擎：MyISAM和InnoDB
0:15:00来源：
mysql 优化系列（一） Mysql数据库引擎性能测试?Mysql 数据库中，最常用的两种引擎是innordb和myisam。Innordb的功能要比myiasm强大很多，但是innordb的性能要比myisam差很多，如果你的网站只是做简单的查询，更新，删除，那么用myiasm是最好的选择。所有的性能测试在：Micrisoft window xp sp2 ， Intel(R) Pentinum(R) M processor 1.6oGHz 1G 内存的电脑上测试。测试结果：测试方法：连续提交10个query， 表记录总数：38万 ， 时间单位 s?引擎类型 Myisam innordb 性能相差?count 0..?查询主键 0..?查询非主键 24.01 80.37 3.348?更新主键 0..?更新非主键 0..?插入 0..结论：1. 加了索引以后，对于Myisam查询可以加快：4 206.09733倍，对innordb 查询加快510.72921倍。同时对myisam更新速度减慢为原来的1/2，innordb的更新速度减慢为原来的1/30。大家要看情况决定是否要加索引，比如不查询的log表，不要做任何的索引。2. 如果你的数据量是百万级别的，并且没有任何的事务处理，那么用myisam是性能最好的选择。3. Innordb的表的大小更加的大，用myisam可以省很多的硬盘空间。?在我们测试的这个38w的表中，表占用空间的情况如下：引擎类型 MyIsam InnorDB?数据 53,924 KB 58,976 KB?索引 13,640 KB 21,072 KB?占用总空间 67,564 KB 80,048 KB?另外一个176W万记录的表， 表占用空间的情况如下：引擎类型 MyIsam InnorDB?数据 56,166 KB 90,736 KB?索引 67,103 KB 88,848 KB?占用总空间 123,269 KB 179,584 KB?MyIsam引擎和InnorDB引擎简介：MyISAM MyISAM是MySQL的ISAM扩展格式和缺省的数据库引擎。除了提供ISAM里所没有的索引和字段管理的大量功能，MyISAM还使用一种表格锁定的机制，来优化多个并发的读写操作。其代价是你需要经常运行OPTIMIZE TABLE命令，来恢复被更新机制所浪费的空间(学过数据结构的都应该知道，ISAM文件格式的缺陷)。MyISAM还有一些有用的扩展，例如用来修复数据库文件的MyISAMChk工具和用来恢复浪费空间的MyISAMPack工具。MyISAM强调了快速读取操作，这可能就是为什么MySQL受到了Web开发如此青睐的主要原因：在Web开发中你所进行的大量数据操作都是读取操作。所以，大多数虚拟主机提供商和Internet平台提供商（Internet Presence Provider，IPP）只允许使用MyISAM格式。 MYISAM格式的一个重要缺陷就是不能在表损坏后恢复数据。InnorDBInnoDB数据库引擎都是造就MySQL灵活性的技术的直接产品，这项技术就是MySQL++ API。在使用MySQL的时候，你所面对的每一个挑战几乎都源于ISAM和MyISAM数据库引擎不支持事务处理也不支持外来键。尽管要比ISAM和MyISAM引擎慢很多，但是InnoDB包括了对事务处理和外键的支持，这两点都是前两个引擎所没有的。如前所述，如果你的设计需要这些特性中的一者或者两者，那你就要被迫使用后两个引擎中的一个了。Mysql 官方对InnorDB是这样解释的： InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。InnoDB是为处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。 InnoDB存储引擎被完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表＆索引在一个表空间中，表空间可以包含数个文件（或原始磁盘分区）。这与MyISAM表不同，比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸，即使在文件尺寸被限制为2GB的操作系统上。 InnoDB默认地被包含在MySQL二进制分发中。Windows Essentials installer使InnoDB成为Windows上MySQL的默认表。 InnoDB被用来在众多需要高性能的大型数据库站点上产生。著名的Internet新闻站点Slashdot.org运行在InnoDB上。Mytrix, Inc.在InnoDB上存储超过1TB的数据，还有一些其它站点在InnoDB上处理平均每秒800次插入/更新的【来源】 mysql 性能优化（二）今天突然看到一年前写的 mysql 优化（一） ，感觉有些误人子弟。今天再补充一些东西。关于引擎选择，从理论上 和 实际上 可能会有差距，所以，对待mysql 要有实验精神。一般来说，MYisam 适合：1. 做很多count 的计算。2. 插入不平凡，查询非常频繁。3. 没有事务innordb 非常适合：1. 可靠性要求比较高，或者要求事务。2. 表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。当然这也不是绝对的。要试验过才知道。很多时候，性能瓶颈不是因为服务器配置不好，而是因为SQL不是很好。SQL的性能优化是关键。除了这些常见的优化方法， 还可以考虑 使用内存表。你测试一张myisam 和 内存表，会发现速度差不多。其实，在并发比较强的时候，性能会相差大概五倍。我有张经常要查询的IP 地址 和 地区的 对应表，放入内存后。以前查询 5000个 IP 地址大概 要 15S， 现在，只要 2S多。很多东西，实际测试过才知道。用什么压力测试，测试出来的也不是很准确。?【来源】数据库（10）
Innodb引擎
Innodb引擎提供了对数据库ACID事务的支持，并且实现了SQL标准的四种隔离级别。该引擎还提供了行级锁和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL运行时Innodb会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引，而且它没有保存表的行数，当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时，该引擎当然是首选。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。
MyIASM引擎
MyIASM是MySQL默认的引擎，但是它没有提供对数据库事务的支持，也不支持行级锁和外键，因此当INSERT(插入)或UPDATE(更新)数据时即写操作需要锁定整个表，效率便会低一些。不过和Innodb不同，MyIASM中存储了表的行数，于是SELECT COUNT(*) FROM TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持，那么MyIASM也是很好的选择。
主要区别：
1、MyIASM是非事务安全的，而InnoDB是事务安全的
2、MyIASM锁的粒度是表级的，而InnoDB支持行级锁
3、MyIASM支持全文类型索引，而InnoDB不支持全文索引
4、MyIASM相对简单，效率上要优于InnoDB，小型应用可以考虑使用MyIASM
5、MyIASM表保存成文件形式，跨平台使用更加方便
应用场景：
1、MyIASM管理非事务表，提供高速存储和检索以及全文搜索能力，如果再应用中执行大量select操作，应该选择MyIASM
2、InnoDB用于事务处理，具有ACID事务支持等特性，如果在应用中执行大量insert和update操作，应该选择InnoDB
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：21552次
排名：千里之外
原创：55篇
转载：68篇
(12)(31)(32)(29)(3)(3)(2)(1)(5)