count(1)、count(*)与count(列名)的执行区别

在工作中遇到count(*)、count(1)、count(col) ,可能会让你分不清楚,都是计数,干嘛这么搞这么多东西。

count 作用

COUNT(expression):返回查询的记录总数,expression 参数是一个字段或者 * 号。

测试

MySQL版本:5.7.29

创建一张用户表,并插入一百万条数据,其中gender字段有五十万行是为null值的

CREATE TABLE `users` (
  `Id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `name` varchar(32) DEFAULT NULL COMMENT '名称',
  `gender` varchar(20) DEFAULT NULL COMMENT '性别',
  `create_date` datetime DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`Id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='用户表';
复制代码

count(*)

在 MySQL 5.7.18 之前,通过扫描聚集索引来InnoDB处理 语句。SELECT COUNT( *)从 MySQL 5.7.18 开始, 通过遍历最小的可用二级索引来InnoDB处理SELECT COUNT( *)语句,除非索引或优化器提示指示优化器使用不同的索引。如果二级索引不存在,则扫描聚集索引。 大概意思就是有二级索引的情况下就使用二级索引,如果有多个二级索引优先选择最小的那个二级索引来降低成本,没有二级索引使用聚集索引。 下面通过测试来验证这些观点。

  • 首先,在只有Id这一个主键索引的情况下查询执行计划, 在这里插入图片描述 可以看到,type是index也就是使用了索引,key是PRIMARY就是使用了主键索引,key_len=8。
  • 其次在name字段上加上索引,再次使用执行计划查看 在这里插入图片描述 可以看到同样使用了索引,只不过索引用的是name字段的索引,key_len=99。
  • 然后在保留name字段索引的情况下给create_date字段也加上索引,再次查看执行计划 在这里插入图片描述 可以看到这次使用的是create_date字段的索引了,key_len=6。

不管上述是使用了哪个索引,其最后查询到的总行数都是一百万条,无论它们是否包含 NULL值。

count(1)

count(1) 和count(*) 执行查询结果一样,最终也是返回一百万条数据,无论它们是否包含 NULL值。

count(col)

count(col) 统计某一列的值,又分为三种情况:

count(id): 统计id

和count(*) 执行查询结果也是一样,最终也是返回一百万条数据.

count(index col):统计带索引的字段

以count(name)进行查询,执行计划如下:

count(1)、count(*)与count(列名)的执行区别

可以看到用的是索引字段进行统计,索引也命中了。 把一列中的name字段置为NULL,再进行count查询,结果返回999999

count(1)、count(*)与count(列名)的执行区别

再把这列的NULL值置为空字符串,再进行count查询,结果返回1000000

count(1)、count(*)与count(列名)的执行区别

所以,综上简单的使用索引字段统计行数能够命中索引,并且只统计不为NULL值的行数。

count(normal col):统计不带索引的字段

统计不带索引的字段的话就不会使用索引,而且也是只统计不为NULL值的行数。 在这里插入图片描述

count(1)和count(*)取舍

之前也不知道在哪看到的或听说的,count(1) 比count(*) 效率高,这是错误的认知,官网上有这么一句话,InnoDB handles SELECT COUNT( *) and SELECT COUNT(1) operations in the same way. There is no performance difference. 翻译过来就是,InnoDB以同样的方式处理SELECT COUNT( *)和SELECT COUNT(1) 操作,没有性能差异。

对于MyISAM表, 如果从一个表中检索,没有检索到其他列并且没有 子句,COUNT(*)则优化为非常快速地返回 ,此优化仅适用于MyISAM 表,因为为此存储引擎存储了准确的行数,并且可以非常快速地访问。 COUNT(1)仅当第一列定义为 时才进行相同的优化NOT NULL。—-来自MySQL官网 这些优化都是建立在没有where 和 group by的前提下的。

阿里开发规范中也提到 在这里插入图片描述 所以在开发中能用count(*) 就用count( *).

文章来源:https://www.cnaaa.net,转载请注明出处:https://www.cnaaa.net/archives/6613

(0)
郭靖的头像郭靖
上一篇 2023年1月11日 下午4:36
下一篇 2023年1月13日 下午3:10

相关推荐

  • 数据库压力测试

    一、前言 在前面的压力测试过程中,主要关注的是对接口以及服务器硬件性能进行压力测试,评估请求接口和硬件性能对服务的影响。但是对于多数Web应用来说,整个系统的瓶颈在于数据库。 原因很简单:Web应用中的其他因素,例如网络带宽、负载均衡节点、应用服务器(包括CPU、内存、硬盘、连接数等)、缓存,都很容易通过水平的扩展(俗称加机器)来实现性能的提高。而对于MyS…

    2023年3月21日
    1.1K00
  • JetBrains产品安装破解分享–DataGrip

    第一步: 下载最新的 Datagrip 2022.3.1 版本安装包 我们先从 Datagrip 官网下载 Datagrip 2022.3.1 版本的安装包,下载链接如下: 第二步:卸载老版本 Datagrip 卸载时删除本地数据 第三步: 开始安装 DataGrip 2022.3.1 版本 安装路径可更改 创建桌面快捷方式 安装完成后勾选 Run Data…

    2023年3月15日
    1.3K00
  • Oracle用户和表被锁定解决方法

    1、用dba角色的用户登陆,进行解锁,先设置具体时间格式,以便查看具体时间 2、查看具体的被锁时间 3、解锁 4、查看是那个ip造成的test用户被锁 这样可知是上面10.69.1.11的ip尝试多次失败登陆造成的被锁 注: 一般数据库默认是10次尝试失败后锁住用户 1、查看FAILED_LOGIN_ATTEMPTS的值 2、修改为30次 3、修改为无限次(…

    2024年5月9日
    1.5K00
  • 数据库报错:Cause com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure

    原因1.因为SSL连接原因(大部分人的原因)因为MySQL在高版本需要指明是否进行SSL连接。有可能你 pom 文件引入的 MySQL 依赖版本是MySQL5.7及以上 这些的时候,你就需要指定SSL连接,如果你不知道,默认就是开启,所以就会出现上面的错误。 2.因为数据库连接超时原因当数据库重启或数据库空闲连接超过设置的最大timemout时间,数据库会强…

    2023年8月1日
    99500
  • mysql的主从延迟问题主要原因及解决

    MySQL数据库主从的安装搭建方法 在实际的生产中,为了解决Mysql的单点故障已经提高MySQL的整体服务性能,一般都会采用主从复制。 比如:在复杂的业务系统中,有一句sql执行后导致锁表,并且这条sql的的执行时间有比较长,那么此sql执行的期间导致服务不可用,这样就会严重影响用户的体验度。 主从复制中分为主服务器(master)和从服务器(slave)…

    2022年6月14日
    1.9K00

发表回复

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

在线咨询: QQ交谈

邮件:712342017@qq.com

工作时间:周一至周五,8:30-17:30,节假日休息

关注微信