myisam和innodb的区别

发布网友 发布时间:2022-04-18 06:13

我来回答

4个回答

懂视网 时间:2022-04-18 10:34

myisam和innodb的区别如下:

  

  1、InnoDB支持事务,MyISAM不支持,对于InnoDB每一条SQL语言都默认封装成事务,自动提交,这样会影响速度,所以最好把多条SQL语言放在begin和commit之间,组成一个事务。

  

  2、InnoDB支持外键,而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败。

  

  3、InnoDB是聚集索引,使用B加Tree作为索引结构,数据文件是和索引绑在一起的,必须要有主键,通过主键索引效率很高。但是辅助索引需要两次查询,先查询到主键,然后再通过主键查询到数据。因此,主键不应该过大,因为主键太大,其他索引也都会很大。

  

  

热心网友 时间:2022-04-18 07:42

热心网友 时间:2022-04-18 09:00

MYISAM 表是典型的数据与索引分离存储,主键和二级索引没有本质区别。比如在 MYISAM 表里主键、唯一索引是一样的,没有本质区别。
MYISAM 表的索引存储方式最大的缺点没有按照物理数据行顺序存储,这样无论对主键的检索还是对二级索引的检索都需要进行二次排序。
INNODB 表本身是索引组织表,也就是说索引就是数据。下图表T1的数据行以聚簇索引的方式展示,非叶子节点保存了主键的值,叶子节点保存了主键的值以及对应的数据行,并且每个页有分别指向前后两页的指针。
INNODB 表不同于 MYISAM,INNODB 表有自己的数据页管理,默认 16KB。MYISAM 表数据的管理依赖文件系统,比如文件系统一般默认 4KB,MYISAM 的块大小也是 4KB,MYISAM 表的没有自己的一套崩溃恢复机制,全部依赖于文件系统。
INNODB 表这样设计的优点有两个:
1. 数据按照主键顺序存储。主键的顺序也就是记录行的物理顺序,相比指向数据行指针的存放方式,避免了再次排序。
2. 两个叶子节点分别含有指向前后两个节点的指针,这样在插入新行或者进行页*时,只需要移动对应的指针即可。
但是也有缺点:
1. 二级索引由于同时保存了主键值,体积会变大。特别是主键设计不合理的时候,比如用 UUID 做主键。
2. 对二级索引的检索需要检索两次索引树。第一次通过检索二级索引叶子节点,找到过滤行对应的主键值;第二次通过这个主键的值去聚簇索引中查找对应的行。

热心网友 时间:2022-04-18 10:35

  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特性(例如外键)的表不适用。
  另外,InnoDB表的行锁也不是绝对的,假如在执行一个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个月就会发生应用开发人员不小心update一个表where写的范围不对,导致这个表没法正常用了,这个时候MyISAM的优越性就体现出来了,随便从当天拷贝的压缩包取出对应表的文件,随便放到一个数据库目录下,然后mp成sql再导回到主库,并把对应的binlog补上。如果是Innodb,恐怕不可能有这么快速度,别和我说让Innodb定期用导出xxx.sql机制备份,因为最小的一个数据库实例的数据量基本都是几十G大小。
  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,但是那么高并发的写,从库能否追的上也是一个问题,还不如通过多实例分库分表架构来解决。
  7、如果是用MyISAM的话,merge引擎可以大大加快应用部门的开发速度,他们只要对这个merge表做一些select
count(*)操作,非常适合大项目总量约几亿的rows某一类型(如日志,调查统计)的业务表。
  当然Innodb也不是绝对不用,用事务的项目就用Innodb的。另外,可能有人会说你MyISAM无法抗太多写操作,但是可以通过架构来弥补。

声明声明:本网页内容为用户发布,旨在传播知识,不代表本网认同其观点,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。E-MAIL:11247931@qq.com
2.512437s