InnoDB和MyISAM是许多人在使用MySQL时最经常使用的两个表类型，这两个表类型各有优劣，视具体利用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其履行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已外部键等高级数据库功能。
以下是1些细节和具体实现的差别：
◆1.InnoDB不支持FULLTEXT类型的索引。
◆2.InnoDB 中不保存表的具体行数，也就是说，履行select count(*) from table时，InnoDB要扫描1遍全部表来计算有多少行，但是MyISAM只要简单的读出保存好的行数便可。注意的是，当count(*)语句包括 where条件时，两种表的操作是1样的。
◆3.对AUTO_INCREMENT类型的字段，InnoDB中必须包括只有该字段的索引，但是在MyISAM表中，可以和其他字段1起建立联合索引。
◆4.DELETE FROM table时，InnoDB不会重新建立表，而是1行1行的删除。
◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对使用的额外的InnoDB特性(例如外键)的表不适用。
另外，InnoDB表的行锁也不是绝对的，假设在履行1个SQL语句时MySQL不能肯定要扫描的范围，InnoDB表一样会锁全表，例如update table set num=1 where name like “%aaa%”
两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM常常就容易被人认为只合适在小项目中使用。
我作为使用MySQL的用户角度动身，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要到达需求：99.9%的稳定性，方便的扩大性和高可用性来讲的话，MyISAM绝对是我的首选。
缘由以下：
1、首先我目前平台上承载的大部份项目是读多写少的项目，而MyISAM的读性能是比Innodb强很多的。
2、MyISAM的索引和数据是分开的，并且索引是有紧缩的，内存使用率就对应提高了很多。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用紧缩从而会造成Innodb比MyISAM体积庞大不小。
3、从平台角度来讲，常常隔1，2个月就会产生利用开发人员不谨慎update1个表where写的范围不对，致使这个表没法正经常使用了，这个时候MyISAM的优越性就体现出来了，随意从当天拷贝的紧缩包取出对应表的文件，随意放到1个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，由于我平台上最小的1个数据库实例的数据量基本都是几10G大小。
4、从我接触的利用逻辑来讲，select count(*) 和order by 是最频繁的，大概能占了全部sql总语句的60%以上的操作，而这类操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。
5、还有就是常常有很多利用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，由于光给他人文件，受字典数据文件的影响，对方是没法使用的。
6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那末高并发的写，从库能否追的上也是1个问题，还不如通过量实例分库分表架构来解决。
7、如果是用MyISAM的话，merge引擎可以大大加快利用部门的开发速度，他们只要对这个merge表做1些select count(*)操作，非常合适大项目总量约几亿的rows某1类型(如日志，调查统计)的业务表。
固然Innodb也不是绝对不用，用事务的项目如摹拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台利用动身，我还是会首选MyISAM。
另外，可能有人会说你MyISAM没法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天10多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括1个大项目由于早期memcached没部署,致使单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5⑴左右。
| MyISAM |
InnoDB |
|
| 构成上的区分： |
每一个MyISAM在磁盘上存储成3个文件。第1个文件的名字以表的名字开始，扩大名指出文件类型。 .frm文件存储表定义。 数据文件的扩大名为.MYD (MYData)。 索引文件的扩大名是.MYI (MYIndex)。 |
基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小只受限于操作系统文件的大小，1般为 2GB |
| 事务处理上方面: |
MyISAM类型的表强调的是性能，其履行数度比InnoDB类型更快，但是不提供事务支持 |
InnoDB提供事务支持事务，外部键等高级数据库功能 |
| SELECT UPDATE,INSERT，Delete操作 |
如果履行大量的SELECT，MyISAM是更好的选择 |
1.如果你的数据履行大量的INSERT或UPDATE，出于性能方面的斟酌，应当使用InnoDB表 2.DELETE FROM table时，InnoDB不会重新建立表，而是1行1行的删除。 3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对使用的额外的InnoDB特性（例如外键）的表不适用 |
| 对AUTO_INCREMENT的操作 |
每表1个AUTO_INCREMEN列的内部处理。 MyISAM为INSERT和UPDATE操作自动更新这1列。这使得AUTO_INCREMENT列更快（最少10%）。在序列顶的值被删除以后就不能再利用。(当AUTO_INCREMENT列被定义为多列索引的最后1列，可以出现重使用从序列顶部删除的值的情况）。 AUTO_INCREMENT值可用ALTER TABLE或myisamch来重置 对AUTO_INCREMENT类型的字段，InnoDB中必须包括只有该字段的索引，但是在MyISAM表中，可以和其他字段1起建立联合索引 更好和更快的auto_increment处理 |
如果你为1个表指定AUTO_INCREMENT列，在数据词典里的InnoDB表句柄包括1个名为自动增长计数器的计数器，它被用在为该列赋新值。 自动增长计数器仅被存储在主内存中，而不是存在磁盘上 关于该计算器的算法实现，请参考 AUTO_INCREMENT列在InnoDB里如何工作 |
| 表的具体行数 |
select count(*) from table,MyISAM只要简单的读出保存好的行数，注意的是，当count(*)语句包括 where条件时，两种表的操作是1样的 |
InnoDB 中不保存表的具体行数，也就是说，履行select count(*) from table时，InnoDB要扫描1遍全部表来计算有多少行 |
| 锁 |
表锁 |
提供行锁(locking on row level)，提供与 Oracle 类型1致的不加锁读取(non-locking read in SELECTs)，另外，InnoDB表的行锁也不是绝对的，如果在履行1个SQL语句时MySQL不能肯定要扫描的范围，InnoDB表一样会锁全表，例如update table set num=1 where name like “%aaa%” |
MySQL有多种存储引擎，MyISAM和InnoDB是其中经常使用的两种。这里介绍关于这两种引擎的1些基本概念（非深入介绍）。
MyISAM是MySQL的默许存储引擎，基于传统的ISAM类型，支持全文搜索，但不是事务安全的，而且不支持外键。每张MyISAM表寄存在3个文件中：frm 文件寄存表格定义；数据文件是MYD (MYData)；索引文件是MYI (MYIndex)。
InnoDB是事务型引擎，支持回滚、崩溃恢复能力、多版本并发控制、ACID事务，支持行级锁定（InnoDB表的行锁不是绝对的，如果在履行1个SQL语句时MySQL不能肯定要扫描的范围，InnoDB表一样会锁全表，如like操作时的SQL语句），和提供与Oracle类型1致的不加锁读取方式。InnoDB存储它的表和索引在1个表空间中，表空间可以包括数个文件。
主要区分：
利用场景：
经常使用命令：
（1）查看表的存储类型（3种）：
（2）修改表的存储引擎：
（3）启动mysql数据库的命令行中添加以下参数使新发布的表都默许使用事务：
（4）临时改变默许表类型：
程序员人生，我编程，我富裕，记住wfuyu网，php教程，php学习，php手册，CMS模版制作
声明：本站大部分内容是作者原创，少部分收集于互联网供大家一起学习，原版权很多不明，如有侵权请联系本站，谢谢！
粤ICP备14040726号-1 2015-2020 程序员人生 版权所有
