环球头条：count(1)计算一共有多少个字段？count(1)计算一共有多少个固定值？

网上的说法参差不齐啊，想找到个说法还真难：

(相关资料图)

count(1)，其实就是计算一共有多少符合条件的行。1并不是表示第一个字段，而是表示一个固定值。 其实就可以想成表中有这么一个字段，这个字段就是固定值1，count(1)，就是计算一共有多少个1. 同理，count(2)，也可以，得到的值完全一样，count("x")，count("y")都是可以的。一样的理解方式。在你这个语句理都可以使用，返回的值完全是一样的。就是计数。 count(*)，执行时会把星号翻译成字段的具体名字，效果也是一样的，不过多了一个翻译的动作，比固定值的方式效率稍微低一些。

如果实在理解不了：就记住它是用来统计有多少个的就行了~

一、执行结果

count(*) 和count(1) 都是统计行数，而count(col) 是统计col列非null的行数

二、执行计划

MyISAM与InnoDB，正如在不同的存储引擎中，count(*)函数的执行是不同的

在MyISAM存储引擎中，count()函数是直接读取数据表保存的行记录数并返回,效率很高，但是如果添加了where条件的话，MyISAM表也不能返回得很快。

在InnoDB存储引擎中，count(*)函数是先从内存中读取表中的数据到内存缓冲区，然后扫描全表获得行记录数。在使用count函数中加上where条件时，在两个存储引擎中的效果是一样的，都会扫描全表计算某字段有值项的次数。

InnoDB 是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于 count() 这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL 优化器会找到最小的那棵树来遍历。因此表有二级索引，则使用二级索引key_len最小的索引进行扫描，尽管这个二级索引的key_len的值大于主键，都使用二级索引。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

count(字段)

1、如果这个字段定义为not null的话，一行行地从记录里面读出这个字段，判断不能为null，按行累计加1

2、如果这个字段定义允许为null，一行行地从记录里面读出这个字段，执行的时候还要判断是否为null，不为null的按行累计加1，返回累加值

三、执行效率

1、如果在开发中确实需要用到count()聚合，那么优先考虑count(*)，因为mysql本身对于count(*)做了特别的优化处理。

有主键或联合主键的情况下，count(*)略比count(1)快一些。  没有主键的情况下count(1)比count(*)快一些。  如果表只有一个字段，则count(*)是最快的。

2、使用count()聚合函数后，最好不要跟where age = 1；这样的条件，会导致不走索引，降低查询效率。除非该字段已经建立了索引。使用count()聚合函数后，若有where条件，且where条件的字段未建立索引，则查询不会走索引，直接扫描了全表。

3、count(字段),非主键字段，这样的使用方式最好不要出现，因为它不会走索引。

count(主键ID)比count(1)慢的原因？

对于 count(主键 ID) 来说，InnoDB 引擎会遍历主键索引树，把每一行的ID值取出来，返回给server层，server层拿到ID后，判断是不可能为空的，按行累加加1，最后返回累计值。

对于count(1)，InnoDB引擎会扫描主键索引树，但不取值，server层对于返回的每一行，按行累计加1，判断不可能为NULL，返回累计值。

从InnoDB引擎层返回ID会涉及到解析数据行、拷贝字段值的操作，因此count(主键 ID)执行要比count(1)执行慢。

count(主键id)走主键索引的时候效率较count(*)差的原因？

平时我们检索一列的时候，基本上等值或范围查询，那么索引基数大的索引必然效率很高(符合走主键索引查找速度最快的原则)。

但是在做count(*)的时候并没有检索具体的一行或者一个范围，那么选择基数小的索引对count操作效率会更高。在做count操作的时候，mysql会遍历每个叶子节点，所以基数越小，效率越高。mysql非聚簇索引叶子节点保存指向主键ID的指针，所以需要检索两遍索引。但是这里相对于遍历主键索引,即使检索两遍索引效率也比单纯的检索主键索引快。

Innodb是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值，索引普通索引树小很多，索引长度越小树的大小就越小。

看看大神怎么说~：

count(*) 的实现方式

首先，我们来看下它的实现方式。

MySQL 中，不同的存储引擎，count(*) 的实现方式是不同的。

1、MyISAM 引擎，比较简单粗暴，直接将表的总行数存储在磁盘上，因此效率很高；

2、InnoDB 引擎中，执行时，需要一行行的把数据查出来，然后累加；

为啥 MyISAM 就可以这样做呢？因为它不支持事务啊，不用担心数据不一致的问题。

而 InnoDB 就不一样了。

由于 MVCC 的存在，InnoDB 在当前执行环境下，对一共有多少数据行是不确定的，比如：

假设，表 t 中有 1000 条数据，有下面三个用户并行的会话：

1、A 启动事务，查询表的总行数；

2、C 直接插入一条数据，然后查询总行数；

3、B 启动事务，插入一条数据，然后查询总行数；

4、C 查询总行数；

注意，上面启动的事务都没有提交。

A、B、C 查询的结果都不相同。

B 读到的是 1002，是因为可重复读隔离级别的存在，而 C 未开启事务，因此无法看到别的事务的更新；

综上，InnoDB 引擎中，在每一个会话中，都需要逐行读取数据，然后计数返回总行数。

InnoDB 对 count(*) 的优化

InnoDB 中，主键索引存储的是数据，辅助索引存储的只是主键值。

因此，辅助索引比主键索引小得多，轻量得多。

这种情况下，InnoDB 在执行 count(*) 时，就会判断使用哪个索引，会选择最小的树来进行遍历。

小结

1、由于 MyISAM 引擎不需要支持事务，因此可以快速返回 count(*)；

2、show table status 命令虽然返回很快，但是不准确；

3、InnoDB 执行 count(*) 时会遍历全表，因此性能较差；

count(*)、count(1)、count(主键)、count(字段)的区别

以下，基于 InnoDB。

含义区别

count() 是一个聚合函数，对于返回的结果集，会逐行判断，若返回的不是 NULL，就会加 1，否则不加。

因此，count(*)、count(主键 id) 和 count(1) 都表示返回满足条件的结果集的总行数；而 count(字段），则表示返回满足条件的数据行里面，参数“字段”不为 NULL 的总个数。

性能区别

分析性能，考虑以下几个原则：

1、server 层要什么就会返回什么；

2、InnoDB 只返回必要的值；

3、优化器只优化了 count(*)

对于 count(主键id)，InnoDB 会遍历全表，取每行的主键 id，返回给 server 层，server 层拿到数据后，进行判断累加。

对于 count(1)，InnoDB 仍遍历全表，但是不取值，server 层对返回的每一行数据新增一个 1，然后进行判断累加；

因此，count(1) 要更快些，因为无需取值。从引擎返回 id 会涉及到解析数据行，以及拷贝字段值的操作。

对于 count(字段)：

1、如果这个“字段”是定义为 not null 的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加；2、如果这个“字段”定义允许为 null，那么执行的时候，判断到有可能是 null，还要把值取出来再判断一下，不是 null 才累加。

但是 count(*) 是例外，并不会把全部字段取出来，而是专门做了优化，不取值。count(*) 肯定不是 null，按行累加。

结论：按照效率排序的话，count(字段)<COUNT(主键 id)<count(1)≈count(*)，所以我建议你，尽量使用="" count(*)。<="" p="">