14 | count(*)这么慢,我该怎么办?
计算一个表的行数的语句为:select count(*) fromt
。 本文介绍count(*)
语句是怎样实现的,以及MySQL为什么会这么实现。如果应用中有这种频繁变更并需要统计表行数的需求,业务设计上可以怎么做。
count(*)的实现方式
- 在不同的MySQL引擎中,count(*)有不同的实现方式。
- MyISAM引擎把一个表的总行数存在了磁盘上,执行count(*)的时会直接返回, 效率很高; ( 如果加了where 条件 的话,MyISAM表也很慢)
- InnoDB引擎就麻烦了,执行count(*)时,需要把数据一行一行地从引擎里面读出来,然后累积计数。
- 为什么InnoDB不跟MyISAM一样,也把数字存起来呢?
- InnoDB的事务设计有关系,可重复读是它默认的隔离级别,即使是在同一个时刻的多个查询,由于多版本并发控制(MVCC)的原因,InnoDB 表“应该返回多少行”也是不确定的。
-
这个笨笨的MySQL,在执行count(*)操作的时候还是做了优化的。MySQL优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下,尽量减少扫描的数据量。
-
使用
showtable status
命令,输出结果里面也有一个TABLE_ROWS
用于显示这个表当前有多少行, 且命令执行挺快的 。其实 ,索引统计的值是通过采样来估算的。TABLE_ROWS
就是从这个采样估算得来的,因此它也很不准 。 -
小结:
- MyISAM表虽然count(*)很快,但是不支持事务
- showtable status命令虽然返回很快,但是不准确
- InnoDB表直接count(*)会遍历全表,虽然结果准确,但会导致性能问题
用缓存系统保存计数
-
可以用一个Redis服务来保存这个表的总行数。
这个表每被插入一行Redis计数就加1,每被删 除一行Redis计数就减1。这种方式下,
- 读和更新操作都很快
- 但缓存系统可能会丢失更新。
- 在并发系统里面,无法精确控制不同线程的执行时刻的, 所以,即使Redis正常工作,这个计数值还是逻辑上不精确的 。
在数据库保存计数
把这个计数直接放到数据库里单独的一张计数表中 。
- 首先解决了崩溃丢失的问题,InnoDB是支持崩溃恢复不丢数据的。
- 利用“事务”这个特性, 解决计数不精确的问题 。
不同的count用法
在select count(?) fromt
这样的查询语句里 面,count(*)、count(主键id)、count(字段)和count(1)
等不同用法的性能,有哪些差别? ( 基于InnoDB引擎 )
count()
是一个聚合函数,对于返回的结果集,一行行地判断,如果count函数的参数不是NULL,累计值就加1,否则不加。最后返回累计值
count(*)、count(主键id)和count(1)
都表示返回满足条件的结果集的总行数
count(字 段)
,则表示返回满足条件的数据行里面,参数 “字段”不为NULL的总个数
分析性能差别的时候,你可以记住这么几个原则:
- server层要什么就给什么;
- InnoDB只给必要的值;
- 现在的优化器只优化了count(*)的语义为“取行数”,其他“显而易见”的优化并没有做。
-
count(主键id)
:InnoDB引擎会遍历整张表,把每一行的id值都取出来,返回给server 层。server层拿到id后,判断是不可能为空的,就按行累加。 -
count(1)
:InnoDB引擎遍历整张表,但不取值。server层对于返回的每一行,放一个数字**“1”进去**,判断是不可能为空的,按行累加。
单看这两个用法的差别的话,count(1)执行得要比count(主键id)快。因为从引擎返回id会涉及到解析数据行,以及拷贝字段值的操作。
-
count(字段)
:- “字段”为not null,一行行从记录里面读出这个字段,判断不能为 null,按行累加;
- “字段”为null,执行时,判断到有可能是null,还要把值取出来再判断一下,不是null才累加。
-
count(*)是例外
:并不会把全部字段取出来,而是专门做了优化,不取值。count(*)肯定不 是null,按行累加。
- 结论:按照效率排序的话,
count(字段) < count(主键id) < count(1) ≈ count(*)
建议 尽量使用count(*)
小结
- 不同的MySQL引擎中,count(*)有不同的实现方式
- 缓存系统来存储计数值存在:丢失更新,不准确的问题
- 数据库保存计数:解决了崩溃丢失的问题,利用事务解决不准确问题
count(*)、count(主键id)、count(字段)和count(1)
的用法