MySQL 中 MyISAM 中的查询为什么比 InnoDB 快?

27 篇文章 1 订阅
26 篇文章 1 订阅

点击上方“业余草”,选择“置顶公众号”

第一时间获取技术干货和业界资讯!

 

640?wx_fmt=png

 

哎呀,一年之计在于春啊。最近过完年了,微信群里有非常多的小伙伴在问我一下面试方面的问题。比如:有让我出题的,有让我推荐资料的,还有让我推荐公司的。。。

真是太难为我了!也有些人刚开过年,任务不算多。所以,经常酱油,不知道该学习什么?

于是,我发了一套面试题,如下:

640?wx_fmt=png

结果,他们都来要答案了。哎,做伸手党可不好,什么时候才能独立呢?所以,我一一的拒绝了他们。

关于这套面试题,有很多内容,我都写过文章的!今天,我们来写一写第 14 小题。为什么 MyisAM 查询快?

640

关于,这个问题,我网上看了很多答案。大多内容都雷同,但是我要强调的是,并不是说 MYISAM 一定比 InnoDB 的 select 快。

其实呢?MyISAM 适合读多,并发少的场景;这个问题要分场景来看。不同的场景,还真不能说 MyISAM 比 InnoDB 中的查询快!

下面我们一起来看看 Innodb 和 Myisam 的 5 大区别:

640

上面的“事务”写错了。不过,我相信大家能看明白其中的解释。

关于“行锁”还是“表锁”,可以看我的这篇文章《InnoDB 的 select 行锁还是表锁》。

关于 count 的区别,可以看我的这篇文章《你真的懂 select count(*) 吗?》。

那么为什么大家喜欢说 MyisAM 查询快呢?那是因为,InnoDB 的表是根据主键进行展开的 B+tree 的聚集索引。MyIsam 则非聚集型索引,myisam 存储会有两个文件,一个是索引文件,另外一个是数据文件,其中索引文件中的索引指向数据文件中的表数据。

聚集型索引并不是一种单独的索引类型,而是一种存储方式,InnoDB 聚集型索引实际上是在同一结构中保存了 B+tree 索引和数据行。当有聚簇索引时,它的索引实际放在叶子页中。

640

结合上图,可以看出:INNODB 在做 SELECT 的时候,要维护的东西比 MYISAM 引擎多很多。

640?wx_fmt=png

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

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

640?wx_fmt=png

说白了,为什么现在一些人喜欢 NoSQL 呢?因为 nosql 本身似乎应该是以省去解析和事务锁的方式来提升效能。MYISAM 不支持事务,也是它查询快的一个原因!

原文链接:MySQL 中 MyISAM 中的查询为什么比 InnoDB 快?

640

10T技术资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,GO等等。在公众号内回复对应关键字或框架名字,即可免费获取!!

 你再主动一点点 640?  我们就有故事了

  • 13
    点赞
  • 71
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 9
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

业余草

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值