第十四章 count(*)这么慢，我该怎么办？
count(*) 的实现方式
在不同的 MySQL 引擎中，count(*) 有不同的实现方式：
-
MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行count(*) 的时候会直接返回这个数，效率很高 - 而
InnoDB 引擎就麻烦了，它执行count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数
为什么 InnoDB 不跟 MyISAM 一样，也把数字存起来呢 ?
- 和 InnoDB 的事务设计有关系，可重复读是它默认的隔离级别，在代码上就是通过多版本并发控制，也就是 MVCC 来实现的。
- 每一行记录都要判断自己是否对这个会话可见，因此对于 count(*) 请求来说，InnoDB 只好把数据一行一行地读出依次判断，可见的行才能够用于计算“基于这个查询”的表的总行数。
MySQL 在查询总数的时候会找到最小的那棵树进行遍历，这也是优化的一部分
- B+树只有叶子结点上有数据，全部遍历其实就是对叶子结点的链表进行遍历。
- 此时如果遍历主键索引树，由于其叶子结点上存放的是完整的行信息，对于一个数据页而言其行密度会比较小，最终导致要扫描的数据页较多，进而IO开销也比较大。
- 如果遍历第二索引树，其叶子结点只存放主键信息，其数据页的行密度比较大，最终扫描的数据页较少，节省了IO开销。
show table status 命令中的 TABLE_ROWS 能代替 count(*) 吗 ?
- 不能
- 实际上，TABLE_ROWS 是通过采样估算得来的，因此它也很不准。官方文档说误差可能达到 40% 到 50%。
- 所以，show table status 命令显示的行数也不能直接使用。
总结 count(*)
- MyISAM 表虽然 count(*)很快，但是不支持事务；
-
show table status 命令虽然返回很快，但是不准确； - InnoDB 表直接count(*) 会遍历全表，虽然结果准确，但会导致性能问题
用缓存系统保存计数
将计数保存在缓存系统中的方式，还不只是丢失更新的问题。即使 Redis 正常工作，这个值还是逻辑上不精确的。
- 这里主要原因是因为 “MySQL插入一行数据” 跟 “Redis计数加1” 这两个操作是分开的，不是原子性的，这就很可能在中间过程因为某些并发出现问题。
- 更抽象一点：MySQL 和 Redis 是两个不同的载体，将关联数据记录到不同的载体，而不同载体要实现原子性很难，由于不是原子性很容易引起并发问题。
- 如果能将数据统一在同个载体即 MySQL，并由其保证操作的原子性，即将
插入一行数据和计数加1作为一个完整的事务，通过事务的隔离此时外界看到的就是要么全部执行完毕，要么全部都没执行，进而保持逻辑一致。
在数据库保存计数
- 在数据库中建表计数，可以得到精准的计数，方法是通过数据库中的事务来实现的。
- 计数器的修改和数据的写入都在一个事务中。
- 读取计数器和查询最近数据也在一个事务中。
不同的 count 用法
count(*)、count(主键 id)、count(字段) 和 count(1) 等不同用法的性能差别 ?
-
count(主键 id)：InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不为空的，就按行累加 -
count(1)：InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不为空的，按行累加 -
count(字段)：
- 如果这个 “字段” 是定义为 not null 的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加
- 如果这个 “字段” 定义允许为 null，那么执行的时候，判断到有可能是 null，还要把值取出来再判断一下，不是 null 才累加
-
count(*)：并不会把全部字段取出来，而是专门做了优化，不取值。count(*) 肯定不是 null，按行累加 - 按照效率排序的话：
count(字段) < count(主键 id) < count(1) ≈ count(*) - 所以，尽量使用
count(*)
