[置顶] MySQL的存储引擎-Innodb MyISAM差异

MySQL的存储引擎-InnoDB MyISAM差异

MySQL的的的存储引擎是经常被问到的一个知识点，在这里我自己做了一些整理，其中有一些网络上资料，做了一些归档整理，还有一些自己见解，接下来我从四个方面为大家讲解存储引擎InnoDB的和MyISAM数据的差异。

一，存储引擎 - 引擎类型

MySQL的的支持的存储引擎：MyISAM数据的Innodb的的内存NDB存档
.InnoDB的和MyISAM数据的是许多人在使用MySQL的的时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定基本的差别为：的MyISAM数据类型不支持事务处理等高级处理，而InnoDB的的类型支持.MyISAM类型的表强调的是性能，其执行数度比的InnoDB的类型更快，但是不提供事务支持，而InnoDB的提供事务支持以及外部键等高级数据库功能
。MyISAM的是MySQL的默认存储引擎，基于传统的ISAM类型，支持全文搜索，但不是事务安全的，而且不支持外键每张MyISAM数据表存放在三个文件中：FRM文件存放表格定义;数据文件是MYD（MYData）;索引文件是MYI（MYIndex）;
InnoDB的表是行锁不是绝对的，如果在执行一个SQL语句时MySQL的的不能确定要扫描的范围，InnoDB的的表同样会锁全表如像操作时的SQL语句），以及提供与甲骨文类型一致的不加锁读取方式.InnoDB存储它的表和索引在一个表空间中，表空间可以包含数个文件。

二，主要区别/应用场景

 主要区别：

   MyISAM是非事务安全型的，而InnoDB是事务安全型的。MyISAM
    锁的粒度是表级，而InnoDB则支持行级锁定。MyISAM
    支持全文类型索引，而InnoDB不支持全文索引
    。MyISAM相对简单，所以在效率上面优于InnoDB，小型应用可以考虑使用MyISAM。MyISAM
  表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。InnoDB
  表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablenametype = innodb）。
 

 应用场景：

  MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择
   。InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB的，这样可以提高多用户并发操作的性能

三，的MyISAM和InnoDB的详解主要区别

 

1，事务处理
  innodb支持事务功能，myisam不支持。

  Myisam的执行速度更快，性能更好。

2，select,update ,insert ,delete操作
  MyISAM：如果执行大量的SELECT，MyISAM是更好的选择

  InnoDB：如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表

3，锁机制不同
  InnoDB为行级锁，myisam为表级锁。

注意：当数据库无法确定，所找的行时，也会变为锁定整个表。

如： updatetable set num = 10 where username like "%test%";

4，查询表的行数不同
  MyISAM：selectcount(*) from table,MyISAM只要简单的读出保存好的行数，注意的是，  当 count(*)语句包含  where条件时，两种表的操作是一样的

 InnoDB： InnoDB中不保存表的具体行数，也就是说，执行selectcount(*) from table时，InnoDB要扫描一遍整个表来计算有多少行

5，物理结构不同

 MyISAM：每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。

  .frm文件存储表定义。

  数据文件的扩展名为.MYD(MYData)。

  索引文件的扩展名是.MYI(MYIndex)

InnoDB：基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB表的大小只受限于操作系统文件的大小，一般为2GB

6，anto_increment机制不同

更好和更快的auto_increment处理
其他：为什么MyISAM会比Innodb的查询速度快。
INNODB在做SELECT的时候，要维护的东西比MYISAM引擎多很多；

数据块，INNODB要缓存，MYISAM只缓存索引块， 
这中间还有换进换出的减少；
innodb寻址要映射到块，再到行，MYISAM记录的直接是文件的OFFSET，定位比INNODB要快
INNODB还需要维护MVCC一致；虽然你的场景没有，但他还是需要去检查和维护

MVCC( Multi-Version Concurrency Control )多版本并发控制
InnoDB：通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLEREAD时这种策略是如何应用到特定的操作的：

SELECTInnoDB必须每行数据来保证它符合两个条件：

1、InnoDB必须找到一个行的版本，它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前，或者事务创建时，或者修改了这行数据的时候，这行数据是存在的。

2、这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。

四,实际应用

我们在从实际应用角度考虑如何选择引擎

两种类型最主要的差别就是Innodb支持事务处理与外键和行级锁。而MyISAM不支持.所以MyISAM往往就容易被人认为只
ba24
适合在小项目中使用。
作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，如果数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是首选。

1、平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为最小的一个数据库实例的数据量基本都是几十G大小。

4，从接触的应用逻辑来说，selectcount（*）和排序依据是最频繁的，大概能占了整个SQL总语句的60％以上的操作，而这种操作Innodb的其实也是会锁表的，很多人以为Innodb的的的英文行级锁，只是那个其中对它主键的英文有效值，非主键的都会锁全表的。

5，还有就是经常有很多应用部门需要我给他们定期某些表的数据，的的MyISAM的话很方便，只要发给他们对应那表的frm.MYD，MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb的的就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

如果MyISAM的插入写操作的话，Innodb的的还达不到的的MyISAM的写性能，如果是针对基于索引的更新操作，虽然MyISAM的数据可能会逊色Innodb的的，但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

如果是用的的MyISAM的话，合并引擎可以大大加快应用部门的开发速度，他们只要对这个合并表做一些selectcount（*）操作，非常适合大项目总量约几亿的行某一类型（如日志，调查统计）的业务表。

 

最终选择引擎，根据实际的项目去选择，看项目是写入和查询哪个更多，来选择引擎，如果不需要支持事务，写入比较少，就选择的MyISAM的，查询快，恢复数据也比较安全。