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

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

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

 

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?  我们就有故事了

业余草 CSDN认证博客专家 Java Go/GoLang Redis
如今的编程是一场程序员和上帝的竞赛,程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止,上帝是赢的。个人网站:www.xttblog.com。个人微信:codedq或dart996
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页