MYSQL统计行数时到底应该怎么COUNT
相信每个人在写代码时都有遇到过要获取MYSQL表里数据行数的情况，多数人获取数据表行数时都用COUNT(*)，但同时也流传了不少其他方式，比如说COUNT(1)、COUNT(主键)、COUNT(字段)。到底哪种方式MYSQL执行起来更快也是众说纷纭，其实之前我也不知道到底哪个执行起来快，到底谁说的对(笑哭)。好在最近在认真学习极客时间的MySQL专栏，其中专门有一节是对这个问题的讨论，看完后也是解除了长久以来的疑惑。
文章中都是针对MySQL的InnoDB引擎展开讨论的，MyISAM引擎是把一个表的总行数记录在了磁盘里，查询时效率很高(如果加了where条件也不能直接从磁盘返回)。而InnoDB由于多版本并发控制（MVCC）的原因，即使时同一时刻的查询InnoDB表应该"返回多少行"也是不确定的，比如假设表t中有10000行数据：
| 时刻 | 会话A | 会话B | 会话C |
|---|---|---|---|
| T1 | begin; | ||
| T2 | select count(*) from t; | ||
| T3 | insert into t (插入一行); | ||
| T4 | begin; | ||
| T5 | insert into t (插入一行); | ||
| T6 | select count(*) from t; （返回10000） | select count(*) from t; （返回10002）; | select count(*) from t; （返回10001） |
会话A在T1开启事务拿到一致性视图，可重复读级别下在事务中任何时刻读到数据都一样，其他事务的更新对会话A没影响所以count(*)的结果是10000，会话B在T4开启事务拿到一致性视图，T4之前会话C已经新插入了一条语句并提交（单独执行一条更新语句，InnoDB会自己启动一个事务，语句执行完马上提交）。会话B在T5插入一条新数据，在T6查询时count(*)的结果是10002(T4 begin时会话C insert语句已经提交，所以在会话B的事务中能看到这个更新)。由于会话B在T6时事务还没有提交，会话C看不到会话B的更新，所以会话C在T6时count(*)的结果是10001。
COUNT是一个聚合函数，它的功能是对返回的结果集中每一行进行判断，如果COUNT函数的参数不是NULL则累加1，否则不累加，最后返回累计值。接下来看一下每个COUNT版本的执行效率：
COUNT(主键ID) InnoDB遍历全表，把每一行的主键值都取出来返回给MySQL的Server层，因为主键不可能为NULL，Server层直接按行累加最后返回累计值给客户端。
COUNT(1) 遍历全表但不取值，Server层对返回的每一行放个数字"1"进去，按行累加。COUNT(1)比COUNT(主键)快，因为不需要取值，减少了数据传输。
COUNT(字段) 遍历全表，一行行从记录中读出字段值给Server层，Server层判断值不为NULL了再累加。
COUNT(*)MySQL专门做了优化，会找到表中最小的索引树，InnoDB普通索引树比主键索引小很多，对于COUNT(*)遍历哪个树是一样的，count(*)时MySQL不取记录值，count(*)也肯定不为NULL，Server层中直接按行累加。
所以这个版本COUNT的从低到高分别为：
COUNT(字段) < COUNT(主键) < COUNT(1) ≈ COUNT(*)
所以建议你尽量使用count(*)来获取记录行数。
另外要注意，很多人为了销量会把表的行数记录到Redis中，但这样不能保证Redis里的计数和MySQL表里的数据保持精确一致，这是两个不同的存储系统不支持分布式事务所以就无法拿到精确的一致性视图，如果为了效率把表行数单独存储那么最好存放在一个单独的MySQL表里，这样无法拿到一致性视图的问题就能解决了。
关于MySQL更详细的分析，推荐关注MySQL实战45讲