为什么 select count(*) from t,在 InnoDB 引擎中比 MyISAM 慢?

为什么 select count(*) from t,在 InnoDB 引擎中比 MyISAM 慢?

大家好,又见面了,我是全栈君。

点击上方“ 码农编程进阶笔记 ”,选择“置顶或者星标”

文末有干货,每天定时与您相约!

统计一张表的总数量,是我们开发中常有的业务需求,通常情况下,我们都是使用 select count(*) from t SQL 语句来完成。随着业务数据的增加,你会发现这条语句执行的速度越来越慢,为什么它会变慢呢?

为什么会变慢?想要得到答案就需要知道 MySQL 是如何统计总数量的,先说一个前提吧,count(*) 的具体实现是由存储引擎实现的,也就是说不同的存储引擎实现的方式不一样。标题:为什么select count( * ) from t,在 InnoDB 引擎中比 MyISAM 慢?也是高频面试题。

InnoDB和MyISAM 是我们常用的 MySQL 存储引擎,所以主要对比一下 count(*) 在 InnoDB 和 MyISAM 中的实现:

  • 「在 MyISAM 存储引擎中,把表的总行数存储在磁盘上,当执行 select count(*) from t 时,直接返回总数据」。

  • 「在 InnoDB 存储引擎中,跟 MyISAM 不一样,没有将总行数存储在磁盘上,当执行 select count(*) from t 时,会先把数据读出来,一行一行的累加,最后返回总数量」。

知道了 InnoDB 和 MyISAM 引擎 count(*) 实现之后,为什么select count(*) from t,在 InnoDB 引擎中比 MyISAM 慢?应该有答案了吧,但是这个结论需要有一个前提,就是统计 SQL 不带过滤条件。如果 统计数量 SQL 语句为:select count(*) from t where x = 23,那么在 MyISAM 中就不一定比 InnoDB 快了。

「InnoDB 中 count(*) 语句是在执行的时候,全表扫描统计总数量,所以当数据越来越大时,语句就越来越耗时了」,为什么 InnoDB 引擎不像 MyISAM 引擎一样,将总行数存储到磁盘上?这跟 InnoDB 的事务特性有关,由于多版本并发控制(MVCC)的原因,InnoDB 表“应该返回多少行”也是不确定的。

不妨用一个例子来说明一下,假设现在 t 表中有 10000 条数据,现在有三个用户同时访问的会话:

  • 会话 A 先启动事务并查询一次表的总行数。

  • 会话 B 启动事务,插入一行后记录后,查询表的总行数。

  • 会话 C 先启动一个单独的语句,插入一行记录后,查询表的总行数。

为什么 select count(*) from t,在 InnoDB 引擎中比 MyISAM 慢?

会话执行流程图

假设从上到下是按照时间顺序执行的,同一行语句是在同一时刻执行的。可以看出在最后时刻,三个会话返回的总行数不一样。

出现不一样的结果跟 InnoDB 存储引擎有关系,「在默认隔离级别可重复读的情况下,通过多版本并发控制(MVCC)来实现,每一行记录都需要判断自己是否对这个会话可见,因此在统计总数量时,InnoDB 只好把数据一行一行的读取出来判断,只有当前会话可见的才纳入统计中」。所以同一时刻不同会话查询到的数量就不一样。

InnoDB 引擎在 count(*)语句上也做了优化,我们知道,在 InnoDB 存储引擎中是以索引组织表的方式存储数据,主键索引树上叶子节点存放在所有的数据,而普通索引树的叶子节点是主键值,所以普通索引树会比主键索引树小很多,但是数量是一样的,也就是说遍历主键索引树和普通索引树得到的结果都是一样的。MySQL 就利用了这一特性,在 InnoDB 中执行 select count(*) from t语句时,MySQL 优化器会找到最小的那棵索引树来遍历,这样可能就可以减少加载次数,在一定程度上提升了 count(*)的执行效率。

在公众号后台回复” Mysql优化 “关键字,即可免费获取MySQL特级优化课程视频。

往日精选文章

Mysql性能优化二:索引优化

MySQL索引失效的几种场景

Mysql性能优化一:SQL语句性能优化

主从配置,读写分离也是性能优化一大要点

为什么 select count(*) from t,在 InnoDB 引擎中比 MyISAM 慢?

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/111842.html原文链接:https://javaforall.net

赞 (0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • struts2在web.xml中配置详情

    struts2在web.xml中配置详情

    2022年2月1日
  • python正则表达式匹配中文(Excel如何根据名字匹配编码)

    字符串的编码乱码问题由来已久,真的是令人头疼。这不是在做正则匹配中文时候,编码又一次成了拦路虎,在这儿记录两点。第一,字符串编码。第二,正则匹配中文。早期编码都用ASCII编码,用一个字节来处理编码。如大写A编码为65,但处理中文时候,一个字节显然不够,至少两哥字节,还不能和ASCII冲突,,中国制定GB2312编码,把中文编进去。类似的,韩国,日本都出来格子标准,结果就是多语言混合的文本中会

    2022年4月15日
  • 使用 SCTP 优化网络

    使用 SCTP 优化网络SCTP是在IP网络上使用的一种可靠的通用传输层协议。尽管SCTP协议最初是为发送电话信号而设计的(RFC2960),但带来了一个意外的收获:它通过借鉴UDP的优点解决了TCP的某些局限。SCTP提供的特性使套接字初始化的可用性、可靠性和安全性都得以提高。(图1给出了IP堆栈的层次化架构。)图1.IP栈的层次化架构本文简要介绍了Linux

    2022年6月16日
  • slam技术前景_无人机航拍技术毕业论文

    slam技术前景_无人机航拍技术毕业论文过去几年,扫地机的出现使得SLAM名声大噪,这个被业界认为是实现机器人自主移动的关键技术,已逐渐进入人们的视野,而随着无人驾驶、AGV等行业的兴起,又使其找到了另一片广阔天地。SLAM的前世今生对于定位、定向等需求人们其实在千年前就有了,最早时期,古人提出了夜观天象,基于遥远恒星的方位推断自身所处的位置,进而演变出一门博大精深的学科“牵星术”,用牵星板测量星星实现纬度估计。直到1964…

    2022年9月1日
  • 4月20日

    4月20日

    2021年9月27日
  • 【科普】搜索引擎的工作原理

    【科普】搜索引擎的工作原理昨天的文章全球化的误区,本地化的机会,评论里,有人说,搜索引擎技术似乎不需要本地化,这一看就是彻底不懂这个领域的人讲的。当然,实话说,如果有人说,google在中文本…

    2022年7月19日

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号