Mysql表的七种引擎类型,InnoDB和MyISAM引擎对比区别总结

InnoDB和MyISAM区别总结

我用MySQL的时候用的是Navicat for MySQL（Navicat for mysql v9.0.15注册码生成器）操做库、表操做的，默认的表就是InnoDB类型，也就没有在乎。最近作项目时发现表里除了有InnoDB类型外还有MyISAM类型，上官网看了看以后作如下总结：

原来是MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。 MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，可是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。综述，就能够根据数据表不一样的用处是用不一样的存储类型。并且MyISAM是文件存储的，能够进行直接在不一样操做系统间拷贝使用。

InnoDB：

InnoDB 给 MySQL 提供了具备事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。InnoDB 提供了行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)。这些特性均提升了多用户并发操做的性能表现。在InnoDB表中不须要扩大锁定(lock escalation)，由于 InnoDB 的列锁定(row level locks)适宜很是小的空间。InnoDB 是 MySQL 上第一个提供外键约束(FOREIGN KEY constraints)的表引擎。InnoDB 的设计目标是处理大容量数据库系统，它的 CPU 利用率是其它基于磁盘的关系数据库引擎所不能比的。在技术上，InnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 在主内存中创建其专用的缓冲池用于高速缓冲数据和索引。 InnoDB 把数据和索引存放在表空间里，可能包含多个文件，这与其它的不同，举例来讲，在 MyISAM 中，表被存放在单独的文件中。InnoDB 表的大小只受限于操做系统的文件大小，通常为 2 GB。InnoDB全部的表都保存在同一个数据文件 ibdata1 中（也多是多个文件，或者是独立的表空间文件），相对来讲比较很差备份，能够拷贝文件或用navicat for mysql。

MyISAM

每张MyISAM 表被存放在三个文件 ：frm 文件存放表格定义。 数据文件是MYD (MYData) 。 索引文件是MYI (MYIndex) 引申。
由于MyISAM相对简单因此在效率上要优于InnoDB，小型应用使用MyISAM是不错的选择。
MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去很多的麻烦

 

 

MyISAM 和InnoDB 讲解

　　InnoDB和MyISAM是许多人在使用MySQL时最经常使用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差异为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，可是不提供事务支持，而InnoDB提供事务支持以及外部键等高级数据库功能。

　　如下是一些细节和具体实现的差异：

　　◆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特性(例如外键)的表不适用。

 

 

MyISAM与InnoDB二者之间怎么选择

一、MyISAM不支持事务，InnoDB是事务类型的存储引擎

当咱们的表须要用到事务支持的时候，那确定是不能选择MyISAM了。

二、MyISAM只支持表级锁，BDB支持页级锁和表级锁默认为页级锁，而InnoDB支持行级锁和表级锁默认为行级锁

表级锁：直接锁定整张表，在锁按期间，其余进程没法对该表进行写操做，若是设置的是写锁，那么其余进程读也不容许

MyISAM是表级锁定的存储引擎，它不会出现死锁问题

对于write，表锁定原理以下：

若是表上没有锁，在其上面放置一个写锁，不然，把锁定请求放在写锁队列中。

对于read，表锁定原理以下 ：

若是表上没有写锁定，那么把一个读锁放在其上面，不然把锁请求放在读锁定队列中

当一个锁定被释放时，表可被写锁定队列中的线程获得，而后才是读锁定队列中的线程。这意味着，若是你在一个表上有许多更新，那么你的SELECT语句将等到全部的写锁定

线程执行完。

行级锁：只对指定的行进行锁定，其余进程仍是能够对表中的其余行进行操做的。

行级锁是Mysql粒度最小的一种锁，它能大大的减小数据库操做的冲突，可是粒度越小实现成本也越大。

行级锁可能会致使“死锁”，那究竟是怎么致使的呢，分析缘由：Mysql行级锁并非直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，若是一条sql语句操做了主

键索引，那么Mysql就会锁定这个主键索引，若是sql语句操做的是非主键索引，那么Mysql会先锁定这个非主键索引，再去锁定主键索引。

在UPDATE 和 DELETE操做时Mysql不只会锁定全部WHERE 条件扫描过得索引，还会锁定相邻的键值。

“死锁”举例分析：

表Test：（ID,STATE,TIME） 主键索引：ID 非主键索引：STATE

当执行"UPDATE STATE =1011 WHERE STATE=1000" 语句的时候会锁定STATE索引，因为STATE 是非主键索引,因此Mysql还会去请求锁定ID索引

当另外一个SQL语句与语句1几乎同时执行时：“UPDATE STATE=1010 WHERE ID=1” 对于语句2 Mysql会先锁定ID索引，因为语句2操做了STATE字段，因此Mysql还会请求锁

定STATE索引。这时。彼此锁定着对方须要的索引，又都在等待对方释放锁定。因此出现了"死锁"的状况。

行级锁的优势：

有许多线程访问不一样的行时，只存在少许的冲突。

回滚时只有少许的更改

能够长时间锁定单一的行

行级锁缺点：

相对于页级锁和表级锁来讲占用了更多的内存

当表的大部分行在使用时，比页级锁和表级锁慢，由于你必须得到更多的锁

当在大部分数据上常用GROUP BY操做，确定会比表级锁和页级锁慢。

页级锁：表级锁速度快，可是冲突多；行级锁速度慢，但冲突少；页级锁就是他俩折中的，一次锁定相邻的一组记录。

三、MyISAM引擎不支持外键，InnoDB支持外键

四、MyISAM引擎的表在大量高并发的读写下会常常出现表损坏的状况

咱们正在作的项目就遇到这个问题，表的INSERT 和 UPDATE操做很频繁，原来用的MyISAM引擎，致使表隔三差五就损坏，后来更换成了InnoDB引擎。

其余容易致使表损坏缘由：

服务器忽然断电致使数据文件损坏，强制关机（mysqld未关闭状况下）致使表损坏

mysqld进程在写入操做的时候被杀掉

磁盘故障

表损坏常见症状：

查询表不能返回数据或返回部分数据

打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。

Error: Table 'p' is marked as crashed and should be repaired 。

Incorrect key file for table: '...'. Try to repair it

Mysql表的恢复：

对于MyISAM表的恢复：

可使用Mysql自带的myisamchk工具： myisamchk -r tablename 或者 myisamchk -o tablename（比前面的更保险） 对表进行修复

五、对于count()查询来讲MyISAM更有优点
由于MyISAM存储了表中的行数记录，执行SELECT COUNT() 的时候能够直接获取到结果，而InnoDB须要扫描所有数据后获得结果。
可是注意一点：对于带有WHERE 条件的 SELECT COUNT()语句两种引擎的表执行过程是同样的，都须要扫描所有数据后获得结果

六、 InnoDB是为处理巨大数据量时的最大性能设计，它的CPU效率多是任何其它基于磁盘的关系数据库引擎所不能匹敌的。

七、MyISAM支持全文索引（FULLTEXT），InnoDB不支持

八、MyISAM引擎的表的查询、更新、插入的效率要比InnoDB高

我没有作过详细的测试，就在网上截取了前辈们测试结论：

全部的性能测试在：Micrisoft window xp sp2 ， Intel(R) Pentinum(R) M processor 1.6oGHz 1G 内存的电脑上测试。

测试方法：连续提交10个query， 表记录总数：38万 ， 时间单位 s

引擎类型 MyISAM InnoDB 性能相差

count 0.0008357 3.0163 3609

查询主键 0.005708 0.1574 27.57

查询非主键 24.01 80.37 3.348

更新主键 0.008124 0.8183 100.7

更新非主键 0.004141 0.02625 6.338

插入 0.004188 0.3694 88.21

（1）加了索引之后，对于MyISAM查询能够加快：4 206.09733倍，对InnoDB查询加快510.72921倍，同时对MyISAM更新速度减慢为原来的1/2，InnoDB的更 新速度减慢为原来的1/30。要看状况决定是否要加索引，好比不查询的log表，不要作任何的索引。

（2）若是你的数据量是百万级别的，而且没有任何的事务处理，那么用MyISAM是性能最好的选择。

（3）InnoDB表的大小更加的大，用MyISAM可省不少的硬盘空间。

在咱们测试的这个38w的表中，表占用空间的状况以下：
引擎类型 MyISAM InnoDB
数据 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

 

 

 

　　另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能肯定要扫描的范围，InnoDB表一样会锁全表，例如update table set num=1 where name like “%aaa%”

　　两种类型最主要的差异就是Innodb 支持事务处理与外键和行级锁。而MyISAM不支持.因此MyISAM每每就容易被人认为只适合在小项目中使用。

　　做为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，若是数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来讲的话，MyISAM绝对是首选。

　　缘由以下：

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

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

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

　　四、从接触的应用逻辑来讲，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操做，而这种操做Innodb其实也是会锁表的，不少人觉得Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。

　　五、还有就是常常有不少应用部门须要我给他们按期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们本身在对应版本的数据库启动就行，而Innodb就须要导出xxx.sql了，由于光给别人文件，受字典数据文件的影响，对方是没法使用的。

　　六、若是和MyISAM比insert写操做的话，Innodb还达不到MyISAM的写性能，若是是针对基于索引的update操做，虽然MyISAM可能会逊色Innodb,可是那么高并发的写，从库可否追的上也是一个问题，还不如经过多实例分库分表架构来解决。

　　七、若是是用MyISAM的话，merge引擎能够大大加快应用部门的开发速度，他们只要对这个merge表作一些select count(*)操做，很是适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

　　固然Innodb也不是绝对不用，用事务的项目就用Innodb的。另外，可能有人会说你MyISAM没法抗太多写操做，可是能够经过架构来弥补。

 

 

两种类型最主要的差异就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.因此MyISAM每每就容易被人认为只适合在小项目中使用。

我做为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，可是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来讲的话，MyISAM绝对是个人首选。

缘由以下：

一、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强很多的。

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

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

四、从我接触的应用逻辑来讲，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操做，而这种操做Innodb其实也是会锁表的，不少人觉得Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。

五、还有就是常常有不少应用部门须要我给他们按期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们本身在对应版本的数据库启动就行，而Innodb就须要导出xxx.sql了，由于光给别人文件，受字典数据文件的影响，对方是没法使用的。

六、若是和MyISAM比insert写操做的话，Innodb还达不到MyISAM的写性能，若是是针对基于索引的update操做，虽然MyISAM可能会逊色Innodb,可是那么高并发的写，从库可否追的上也是一个问题，还不如经过多实例分库分表架构来解决。

七、若是是用MyISAM的话，merge引擎能够大大加快应用部门的开发速度，他们只要对这个merge表作一些select count(*)操做，很是适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

固然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，所以我我的也是很喜欢Innodb的，只是若是从数据库平台应用出发，我仍是会首选MyISAM。

另外，可能有人会说你MyISAM没法抗太多写操做，可是我能够经过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，天天十多亿 pv的动态页面，还有几个大项目是经过数据接口方式调用未算进pv总数，(其中包括一个大项目由于初期memcached没部署,致使单台数据库天天处理 9千万的查询)。而个人总体数据库服务器平均负载都在0.5-1左右。

 

 

 

 

 
所谓事务处理，就是原子性操做。
打个比方，支持事务处理的Innodb表，建设一个中，发帖是给积分的。你发了一个帖子执行一个insert语句，来插入帖子内容，插入后就要执行一个update语句来增长你的积分。假设一种特殊状况忽然发生，insert成功了，update操做却没有被执行。也就是说你发了帖子却没有增长相应的积分。这就会形成用户不满。若是使用了事务处理，insert和update都放入到事务中去执行，这个时候，只有当insert和update两条语句都执行生成的时候才会将数据更新、写入到中，若是其中任何一条语句失败，那么就会回滚为初始状态，不执行写入。这样就保证了insert和update确定是一同执行的。 
 mysiam表不支持事务处理，同时mysiam表不支持外键。外键不用说了吧？不知道的话，去网上查吧。
同时，在执行数据库写入的操做（insert,update,delete）的时候，mysiam表会锁表，而innodb表会锁行。通俗点说，就是你执行了一个update语句，那么mysiam表会将整个表都锁住，其余的insert和delete、update都会被拒之门外，等到这个update语句执行完成后才会被依次执行。
而锁行，就是说，你执行update语句是，只会将这一条记录进行锁定，只有针对这条记录的其余写入、更新操做会被阻塞并等待这条update语句执行完毕后再执行，针对其余记录的写入操做不会有影响。
所以，当你的数据库有大量的写入、更新操做而查询比较少或者数据完整性要求比较高的时候就选择innodb表。当你的数据库主要以查询为主，相比较而言更新和写入比较少，而且业务方面数据完整性要求不那么严格，就选择mysiam表。由于mysiam表的查询操做效率和速度都比innodb要快

 

 

 

myslq innodb
我发现同事在项目作压力测试的时候，误解了innodb_flush_log_at_trx_commit的含义，认为配置为0是不写日志，因此性能高。
配置项说明
0

若是innodb_flush_log_at_trx_commit的值为0,log buffer每秒就会被刷写日志文件到磁盘，提交事务的时候不作任何操做。（执行是由mysql的master thread线程来执行的。主线程中每秒会将重作日志缓冲写入磁盘的重作日志文件(REDO LOG)中。不论事务是否已经提交。）默认的日志文件是ib_logfile0,ib_logfile1

1
当设为默认值1的时候，每次提交事务的时候，都会将log buffer刷写到日志。

2
若是设为2,每次提交事务都会写日志，但并不会执行刷的操做。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒必定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操做，而文件系统是有 缓存的，因此这个写入并不能保证数据已经写入到物理磁盘

默认值1是为了保证完整的ACID。固然，你能够将这个配置项设为1之外的值来换取更高的性能，可是在系统崩溃的时候，你将会丢失1秒的数据。设为0的话，mysqld进程崩溃的时候，就会丢失最后1秒的事务。设为2,只有在操做系统崩溃或者断电的时候才会丢失最后1秒的数据。InnoDB在作恢复的时候会忽略这个值。

刷写的概念
刷写实际上是两个操做，刷（flush）和写（write），区分这两个概念（两个系统调用）是很重要的。在大多数的操做系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操做系统缓存中，操做系统缓存一样指的是内存。并无实际的持久化数据。

因此，一般设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，由于这个时候数据只是存在于操做系统缓存。之因此说“一般”，可能会有丢失不仅1秒的数据的状况，好比说执行flush操做的时候阻塞了。

总结
设为1固然是最安全的，但性能页是最差的（相对其余两个参数而言，但不是不能接受）。若是对数据一致性和完整性要求不高，彻底能够设为2,若是只最求性能，例如高并发写的日志服务器，设为0来得到更高性能

 

 

 

 

 

 

Mysql表的七种类型

Mysql表类型都有哪些是必定须要知道的，下面就为您介绍七种Mysql表类型，但愿能对您学习Mysql表类型有所帮助,须要的朋友能够了解下

学习Mysql数据库，Mysql表类型都有哪些是必定须要知道的，下面就为您介绍七种Mysql表类型，但愿能对您学习Mysql表类型有所帮助。 

MySQL做为当前最为流行的免费数据库服务引擎，已经风靡了很长一段时间，不过也许也有人对于MySQL的内部环境不很了解，尤为那些针对并发性处理的机制。今天，咱们先了解一下Mysql表类型，以及它们的一些简单性质。 

截至目前，MySQL一共向用户提供了包括DBD、HEAP、ISAM、MERGE、MyIAS、InnoDB以及Gemeni这7种Mysql表类型。其中DBD、InnoDB属于事务安全类表，而其余属于事务非安全类表。 

DBD 
Berkeley DB(DBD)表是支持事务处理的表，由Sleepycat软件公司开发。它提供MySQL用户期待已久的功能--事务控制。事务控制在任何数据库系统中都是一个极有价值的功能，由于它们确保一组命令能成功地执行或回滚。 

HEAP 
HEAP表是MySQL中存取数据最快的表。这是由于他们使用存储在动态内存中的一个散列索引，不过若是MySQL或服务器崩溃，这些内存数据将会丢失。 

ISAM 
ISAM表是早期MySQL版本的缺省表类型，直到MyIASM开发出来。建议不要再使用它。 

MERGE 
MERGE是一个有趣的新类型，在3.23.25以后出现。一个MERGE表其实是又一个MyISAM表的集合，合并而成的一个表，主要是为了效率的考虑，由于这样不只仅能够提升速度、搜索效率、修复效率并且还节省了磁盘空间。 

MyIASM 
MyIASM基于了IASM代码，应该能够说是IASM的衍生品，不过增长了很多有用的扩展。它是MySQL的默认数据表类型，基于了传统的ISAM类型，ISAM是Indexed Sequential Access Method（有索引的顺序访问方法）的缩写，通常来讲，它是存储记录和文件的标准方法。与其余存储引擎比较，MyISAM具备检查和修复表格的大多数工具。ISAM表格能够被压缩，并且它们支持全文搜索，不过它们是事务不安全的，并且也不支持外键。若是事务回滚将会形成不彻底回滚，从而不具有原子性。因此假如忽略事务以及访问并发性的话，而且须要执行大量的SELECT检索语句的话，MyISAM将是最好的选择。 

InnoDB 
InnoDB是MySQL 4.0以后推出的一种比较新的数据表类型，这种类型是事务安全的。它与BDB类型具备相同的特性，它们还支持外键。InnoDB表格速度很快具备比BDB还丰富的特性，所以若是须要一个事务安全的存储引擎，建议使用它。若是你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，一样应该使用InnoDB表。对于支持事务的InnoDB类型的表来讲，影响速度的主要缘由是AUTOCOMMIT默认设置是打开的，并且程序没有显式调用BEGIN 开始事务，致使每插入一条都自动提交，严重影响了速度。能够在执行sql前调用begin，多条sql造成一个事物（即便autocommit打开也能够），将大大提升性能。 

Gemeni 
Gemeni表，据据说也是在MySQL 4.0以后推出的，不过截至当前，不多有针对它的介绍，一样应用也就更少了，咱们暂时不做介绍。 

MySQL的数据表类型不少，其中比较重要的是MyISAM，InnoDB这两种。 
这两种类型各有优缺点，须要根据实际状况选择适合的，MySQL支持对不一样的表设置不一样的类型。下面作个简单的对比： 
MyISAM表类型是一种比较成熟稳定的表类型，可是MyISAM对一些功能不支持。

 

 

 

InnoDB,MyISAM引擎对比
在数据规模较大（100万条以上），InnoDB引擎性能有相对优点。

在数据规模较小（10万条如下）,MyISAM引擎性能有相对优点。

 http://www.cnblogs.com/szx_rencaijob/archive/2010/04/28/1723211.html