在开发系统的时候,你可能常常须要计算一个表的行数,好比一个交易系统的全部变动记录总数。这时候你可能会想,一条 select count(*) from t 语句不就解决了吗?web
可是,你会发现随着系统中记录数愈来愈多,这条语句执行得也会愈来愈慢。而后你可能就想了,MySQL 怎么这么笨啊,记个总数,每次要查的时候直接读出来,不就行了吗。那么今天,咱们就来聊聊 count(*) 语句究竟是怎样实现的,以及 MySQL 为何会这么实现。数据库
你首先要明确的是,在不一样的 MySQL 引擎中,count(*) 有不一样的实现方式。安全
这里须要注意的是,咱们在这里讨论的是没有过滤条件的 count(*),若是加了 where 条件的话,MyISAM 表也是不能返回得这么快的。并发
不管是在事务支持、并发能力仍是在数据安全方面,InnoDB引擎都优于 MyISAM。MySQL从5.6开始默认的存储引擎也是InnoDB。这就是当记录数愈来愈多的时候,计算一个表的总行数会愈来愈慢的缘由。svg
为何 InnoDB 不跟 MyISAM 同样,也把数字存起来呢?这是由于即便是在同一个时刻的多个查询,因为多版本并发控制(MVCC)的缘由,InnoDB表对于“应该返回多少行”也是不肯定的。这里,举个例子。函数
假设一张InnoDB表 t 中如今有 10000 条记录,咱们设计了三个用户并行的会话,使用MySQL默认的可重复读(RR)隔离级别。性能
咱们假设从上到下是按照时间顺序执行的,同一行语句是在同一时刻执行的。
优化
你会看到,在最后一个时刻,三个会话 A、B、C 会同时查询表 t 的总行数,但拿到的结果却不一样。设计
这和 InnoDB 的事务设计有关系,可重复读是它默认的隔离级别,在代码上就是经过多版本并发控制,也就是 MVCC 来实现的。每一行记录都要判断本身是否对这个会话可见,所以对于 count(*) 请求来讲,InnoDB 只好把数据一行一行地读出依次判断,可见的行才可以用于计算“基于这个查询”的表的总行数。3d
固然,MySQL在执行 count(*) 操做的时候仍是作了优化的。InnoDB 是索引组织表,主键索引树的叶子节点是数据页,而普通索引树的叶子节点是主键值。因此,普通索引树比主键索引树小不少。对于count这样的操做,遍历哪一个索引树获得的结果逻辑上都是同样的。所以,MySQL 优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下,尽可能减小扫描的数据量,是数据库系统设计的通用法则之一。
在 select count(?) from t 这样的查询语句里面, count(*) 、count(主键 id)、count(字段) 和 count(1) 等不一样用法的性能,有哪些差异。
首先要弄清楚 count() 的语义。count() 是一个聚合函数,对于返回的结果集,一行行地判断,若是 count 函数的参数不是 NULL,累计值就加 1,不然不加。最后返回累计值。
因此,count(*)、count(主键 id) 和 count(1) 都表示返回知足条件的结果集的总行数;而 count(字段),则表示返回知足条件的数据行里面,参数“字段”不为 NULL 的总个数。
至于分析性能差异的时候,你能够记住这么几个原则:
接下来,咱们就一个个地来看看。对于 count(主键 id) 来讲,InnoDB 引擎会遍历整张表,把每一行的 id 值都取出来,返回给 server 层。server 层拿到 id 后,判断是不可能为空的,就按行累加。
对于 count(1) 来讲,InnoDB 引擎遍历整张表,但不取值。server 层对于返回的每一行,放一个数字“1”进去,判断是不可能为空的,按行累加。
单看这两个用法的差异的话,就能对比出来,count(1) 执行得要比 count(主键 id) 快。由于从引擎返回 id 会涉及到解析数据行,以及拷贝字段值的操做。
对于 count(字段) 来讲:
也就是前面的第一条原则,server 层要什么字段,InnoDB 就返回什么字段。
可是 count(*) 是例外,并不会把所有字段取出来,而是专门作了优化,不取值。count(*) 确定不是 null,按行累加。
看到这里,你必定会说,优化器就不能本身判断一下吗,主键 id 确定非空啊,为何不能按照 count(*) 来处理,多么简单的优化啊。固然,MySQL 专门针对这个语句进行优化,也不是不能够。可是这种须要专门优化的状况太多了,并且 MySQL 已经优化过 count(*) 了,你直接使用这种用法就能够了。
因此结论是:按照效率排序的话,count(字段)<count(主键 id)<count(1)≈count(*),因此尽可能使用 count(*)。