14 count(*)
count(*)实现方式
首先要声明，在不同的mysql引擎中，count(*)有不同的实现方式。
--myisam引擎把一个表的总行数存在了磁盘，因此执行count(*)的时候会直接返回这个树，效率很高。
--而innodb引擎就麻烦了，执行count(*)的时候，需要把数据一行一行的从引擎里面读出来，然后累计计数。
这里需要注意的是，这篇文章里讨论的是没有过滤条件的count，如果加了where条件的话，myisam表也不是能返回这么快的。
为什么innodb不跟myisam一样，也把数字存起来呢？
这是因为即使是在同一时刻的多个查询，由于多版本并发控制MVCC的原因，innodb表”应该返回多少行”也是不确定。这里，举一个例子
假设表t中现在有10000条记录，设计了三个用户并行的会话
--会话a先启动一个事务并查询一次表的总数
--会话b启动事务，插入一行记录后，查询表的总数
--会话c先启动一个单独的语句，插入一行，查询表的总行数。
|
Session a |
Session b |
Session c |
|
begin; select count(*) from t; |
||
|
insert into t(插入一行) |
||
|
begin; insert into t(插入一行) |
||
|
select count(*) from t; 返回10000 |
select count(*) from t; 返回10002 |
select count(*) from t; 返回10001 |
你会看到，在最后一个时刻，三个会话a、b、c会同时查询表t的总数，但拿到的结果却不一样。
对于innodb来说，count(*)请求，innodb会把数据一行一行地读出来依次判断，可见的行才能够被统计。
Innodb是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值，所以，普通索引树比主键索引树小很多，对于count(*)这样的操作，
遍历那个索引树得到的结果逻辑上都是一样的，因此，mysql优化器会找最小的那棵树来遍历，在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。
用过show table status的话，发现这个命令输出结果里面也有table_rows用于显示这个表有多少行，这个命令执行挺快的，但是能用table_rows代替count(*)吗？
索引统计的值是通过采样估计计算的，实际上，table_rows就是从这个采样估算得来的，所以，table_rows不能直接使用。
--myisam表虽然count(*)很快，但不支持事务
--show table status命令返回虽然快，但是不准确
--innodb表直接count(*)会遍历全表，虽然结果准确，但会导致性能问题。
用缓存系统保存计数
对于更新频繁的库来说，你可能第一时间会想到，用缓存系统来支持计数
你可以用一个redis服务来保存这个表的总行数，这个表每被插入一行redis计数就加1，每被删除一行redis计数就减1，这种方式下，读和更新操作都很快，但是，这种方式会存在缓存系统可能会丢失更新。
Redis的数据不能永远留在内存里，所以会找个地方把这个值持久化的存储起来，即使这样，仍然可能丢失更新，redis异常重启，到数据库单独执行一次count(*)来保证计数的正确性。
在并发系统里面，无法精确控制不同线程的执行时刻的，计数在逻辑上可能不精确。
在数据库保存计数
如果把计数直接放到数据库里单独的一张计数表中，又会怎么样呢？
首先，这解决了崩溃丢失的问题，innodb是支持崩溃恢复不丢失数据的。
然后，看能不能解决计数不精确的问题
利用事务特性来保证逻辑上的一致
begin;
计数表数值加1
插入一行数据
commit;
不同的count用法
在select count(?) from t,这样的查询里面count(*),count(pk id),count(col),count(1)等不同用法的性能有那些差别
基于innodb引擎，count()语义是一个聚合函数，对于返回的结果集，一行行的判断，如果count函数的参数不是null，累计值加1，否则不加，最后返回累计值。
所以，count(*),count(pk id),count(1)都表示返回满足条件的结果集的总行数，而count(col)则表示返回满足条件的数据行里面，参数字段不为null的总个数。
至于分析性能差别的时候，可以记住这几个原则
--server层要什么就给什么
--innodb只给必要的值
--现在的优化器只优化了count(*)的语义为取行数，其他的优化并没有做
对于count(pk id)来说，innodb引擎会遍历整张表，把每一行的id值都取出来，返回给server层，server层拿到id后，判断是不可能为null的，就按行累加
对于count(1)来说，innodb引擎遍历整张表，但不取值，server层对于返回的每一行，放一个数字”1进去，判断是不可能为null的，按行累加
单看这两个用法的差别的话，能对比出来，count(1)执行要比count(pk id)快，因为从引擎返回id会涉及到解析数据行，以及拷贝字段值的操作。
对于count(col)来说
--如果这个字段定义为not null，一行行地从记录里面读出这个字段，判断不能为null，按行累加
--如果这个字段定义允许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加
但是count(*)是例外，并不会把全部字段取出来，而是专门做了优化，不取值，count(*)肯定不是null，按行累加。
所以结论是：按照效率排序的话，count(col)<count(pk id)<count(1)<count(*),所以，建议尽量用count(*).