MyISAM和InnoDB的区别

Love The Way You Lie 2022-05-11 05:04 311阅读 0赞

一、关于count(*)

知识点:MyISAM会直接存储总行数,InnoDB则不会,需要按行扫描。

潜台词是,对于select count(*) from t; 如果数据量大,MyISAM会瞬间返回,而InnoDB则会一行行扫描。

实践:数据量大的表,InnoDB不要轻易select count(*),性能消耗极大。

常见坑:只有查询全表的总行数,MyISAM才会直接返回结果,当加了where条件后,两种存储引擎的处理方式类似。

例如
t_user(uid, uname, age, sex);

  • uid PK
  • age index

select count() where age<18 and sex=’F’;
查询未成年少女个数,两种存储引擎的处理方式类似,都需要进行索引扫描。
\

启示*:不管哪种存储引擎,都要建立好索引。

二、关于全文索引

知识点:MyISAM支持全文索引,InnoDB5.6之前不支持全文索引。

实践:不管哪种存储引擎,在数据量大并发量大的情况下,都不应该使用数据库自带的全文索引,会导致小量请求占用大量数据库资源,而要使用《索引外置》的架构设计方法。

启示:大数据量+高并发量的业务场景,全文索引,MyISAM也不是最优之选。

三、关于事务

知识点:MyISAM不支持事务,InnoDB支持事务。

实践:事务是选择InnoDB非常诱人的原因之一,它提供了commit,rollback,崩溃修复等能力。在系统异常崩溃时,MyISAM有一定几率造成文件损坏,这是非常烦的。但是,事务也非常耗性能,会影响吞吐量,建议只对一致性要求较高的业务使用复杂事务。

画外音:Can’t open file ‘XXX.MYI’. 碰到过么?

小技巧:MyISAM可以通过lock table表锁,来实现类似于事务的东西,但对数据库性能影响较大,强烈不推荐使用。

四、关于外键

知识点:MyISAM不支持外键,InnoDB支持外键。

实践:不管哪种存储引擎,在数据量大并发量大的情况下,都不应该使用外键,而建议由应用程序保证完整性。

五、关于行锁与表锁

知识点:MyISAM只支持表锁,InnoDB可以支持行锁。

分析
MyISAM:执行读写SQL语句时,会对表加锁,所以数据量大,并发量高时,性能会急剧下降。
InnoDB:细粒度行锁,在数据量大,并发量高时,性能比较优异。

实践:网上常常说,select+insert的业务用MyISAM,因为MyISAM在文件尾部顺序增加记录速度极快。楼主的建议是,绝大部分业务是混合读写,只要数据量和并发量较大,一律使用InnoDB。

常见坑
InnoDB的行锁是实现在索引上的,而不是锁在物理行记录上。潜台词是,如果访问没有命中索引,也无法使用行锁,将要退化为表锁。

画外音:Oracle的行锁实现机制不同。

例如
t_user(uid, uname, age, sex) innodb;

  • uid PK
  • 无其他索引

update t_user set age=10 where uid=1;
命中索引,行锁。

update t_user set age=10 where uid != 1;
未命中索引,表锁。

update t_user set age=10 where name=’shenjian’;
无索引,表锁。

启示:InnoDB务必建好索引,否则锁粒度较大,会影响并发。







































引擎/区别

MyISAM

  InnoDB

  构成上的区别:

  

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

  .frm文件存储表定义。

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

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

  

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

 

  事务处理上方面:

  

  MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持

  

  InnoDB提供事务支持事务,外部键等高级数据库功能

  

  SELECT   UPDATE,INSERT,Delete操作
  

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

  

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

  2.DELETE   FROM table时,InnoDB不会重新建立表,而是一行一行的删除。

  3.LOAD   TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用

  

  对AUTO_INCREMENT的操作

  
  

  每表一个AUTO_INCREMEN列的内部处理。

  MyISAM为INSERT和UPDATE操作自动更新这一列。这使得AUTO_INCREMENT列更快(至少10%)。在序列顶的值被删除之后就不能再利用。(当AUTO_INCREMENT列被定义为多列索引的最后一列,可以出现重使用从序列顶部删除的值的情况)。

  AUTO_INCREMENT值可用ALTER TABLE或myisamch来重置

  对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中,可以和其他字段一起建立联合索引

  更好和更快的auto_increment处理

  

  如果你为一个表指定AUTO_INCREMENT列,在数据词典里的InnoDB表句柄包含一个名为自动增长计数器的计数器,它被用在为该列赋新值。

  自动增长计数器仅被存储在主内存中,而不是存在磁盘上

  关于该计算器的算法实现,请参考

  AUTO_INCREMENT列在InnoDB里如何工作

  

  表的具体行数
  

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

  

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

  

  
  

  表锁

  

  提供行锁(locking on row level),提供与 Oracle 类型一致的不加锁读取(non-locking read in
   SELECTs),另外,InnoDB表的行锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,例如update table set num=1 where name like “%aaa%”

总结

在大数据量,高并发量的互联网业务场景下,对于MyISAM和InnoDB

  • 有where条件,count(*)两个存储引擎性能差不多
  • 不要使用全文索引,应当使用《索引外置》的设计方案
  • 事务影响性能,强一致性要求才使用事务
  • 不用外键,由应用程序来保证完整性
  • 不命中索引,InnoDB也不能用行锁

结论

在大数据量,高并发量的互联网业务场景下,请使用InnoDB:

  • 行锁,对提高并发帮助很大
  • 事务,对数据一致性帮助很大

发表评论

表情:
评论列表 (有 0 条评论,311人围观)

还没有评论,来说两句吧...

相关阅读

    相关 InnoDBMyISAM区别

    一、数据存放结构不同 InnoDB和MyISAM是Mysql的两种存储引擎,所谓`存储引擎,就是数据文件的组织方式`,其最大的不同,就是数据存储的结构和方式不一样。Inn

    相关 InnoDBMyISAM区别

    MySQL作为当前最为流行的免费数据库服务引擎,已经风靡了很长一段时间,不过也许也有人对于MySQL的内部环境不很了解,尤其那些针对并发性处理的机制。今天,我们先了解一下MyS