Mysql 存储引擎中InnoDB与Myisam的主要区别

转自：http://blog.sina.com.cn/s/blog_6e322ce70100xwve.html

1， 事务处理

innodb 支持事务功能，myisam 不支持。

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

2，select ,update ,insert ,delete 操作

MyISAM：如果执行大量的SELECT，MyISAM是更好的选择

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

3，锁机制不同

InnoDB 为行级锁，myisam 为表级锁。

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

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

4，查询表的行数不同

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

InnoDB ： InnoDB 中不保存表的具体行数，也就是说，执行select count(*) 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引擎多很多；
1）数据块，INNODB要缓存，MYISAM只缓存索引块，  这中间还有换进换出的减少； 
2）innodb寻址要映射到块，再到行，MYISAM 记录的直接是文件的OFFSET，定位比INNODB要快
3）INNODB还需要维护MVCC一致；虽然你的场景没有，但他还是需要去检查和维护

MVCC ( Multi-Version Concurrency Control )多版本并发控制 

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

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

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

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

事务的四种隔离级别 

转自：http://blog.chinaunix.net/uid-24111901-id-2627894.html

Innodb引擎室mysql server中支持事务的存储引擎之一，

自然也是支持四种事务隔离级别的

read uncommitted，

read commit，

repeatable read

serializable，

下面就分别最四种隔离级别在实现的锁机制做一个简介：
serializable：

1:这种隔离级别对数据的要求最为严格，自然也是性能最差的一种隔离级别。

在所有的select语句中都是默认加了一个lock in share mode的锁，

2：在这种隔离级别中没有一致读的，所有的select都将返回最近的数据状态。

3：由于这种隔离级别的对数据高度一致的严格，所以会产生很多的锁，自然也会导致很多的死锁，对性能的影响不言而喻。

repeatable read：

1：所有的select在第一次一致读以后在事务中都会使用一样的数据状态快照。

2：update，delete都会使用间隙锁来保证数据的安全。防止phantom。

3：这是采用最广的事务隔离级别，也是mysql默认的事务隔离级别。

read commited:

1:每一个select都会使用各自的数据状态的快照。

2:如果当前的数据状态已更新到最新，但是当当个select的时候仍然会产生不一致的数据状态。

3:更少的间隙锁意味着更少的死锁。

4:唯一key的检查在第二索引和其它外键检查的时候也会产生间隙所。（gap必须被锁定以防止在parent row被删除后仍在child row中插入相关数据）。

5:这种隔离级别也是使用的非常普遍的隔离级别尤其是在5.1以后的版本中。

6：征对在5.0更早的版本中，可以通过innodb_locks_unsafe_for_binlog移除gap locking。

（In V5.1, most gap-locking is removed w/ this level, but you MUST use row-based logging/replication。）

read uncommitted：

1：这种隔离级别几乎不被使用，在selelct将会看到各种奇怪的数据现象，当然包括其它事务还未提交的数据。

2：强烈不推荐，不能保证数据的一致性。