MySQL学习笔记-8-count(*)

I、count实现方式（无where条件时）

MyISAM引擎：把一个表的总行数存在了磁盘上，执行 count时直接返回，效率很高；
InnoDB引擎：把数据一行一行地从引擎里面读出来，然后累积计数。

1、有where条件时，MyISAM和InnoDB实现方式一样
2、由于MVCC（多版本并发控制），InnoDB引擎即使是在同一个时刻的多个查询，“应该返回多少行”也是不确定的。
3、InnoDB默认隔离级别可重复读，代码上通过MVCC实现。每一行记录都要判断自己是否对这个会话可见。
4、InnoDB是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于count操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL 优化器会找到最小的那棵树来遍历。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

II、count缺点

MyISAM虽然count很快，但是不支持事务；
show table status命令虽然返回很快，但是不准确；
InnoDB直接count会遍历全表，虽然结果准确，但会导致性能问题。

因此需要自己实现。

III、用缓存系统保存计数-使用Redis服务保存表的总行数

1、将计数保存在缓存系统中的方式，还不只是丢失更新的问题。即使 Redis 正常工作，这个值还是逻辑上不精确的。

这里主要原因是“MySQL插入一行数据”跟“Redis计数加1”这两个操作是分开的，不是原子性的，这就很可能在中间过程因为某些并发出现问题。 更抽象一点：MySQL和Redis是两个不同的载体，将关联数据记录到不同的载体，而不同载体要实现原子性很难，由于不是原子性很容易引起并发问题。如果能将数据统一在同个载体即MySQL，并由其保证操作的原子性，即将插入一行数据和计数加1作为一个完整的事务，通过事务的隔离此时外界看到的就是要么全部执行完毕要么全部都没执行，进而保持逻辑一致。

2、在并发系统里面，我们是无法精确控制不同线程的执行时刻的。

IV、在数据库保存计数-计数直接存储到数据库里单独的一张计数表

1、在数据库中建表计数，可以得到精准的计数，方法是通过数据库中的事务来实现的。计数器的修改和数据的写表在一个事务中。读取计数器和查询最近数据也在一个事务中。
2、解决办法：将计数的记录 + 1和插入一条数据放入到同一个事务中。

V、count

1、count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最后返回累计值。
2、对于count(主键id)来说，InnoDB引擎会遍历整张表，把每一行的id值都取出来，返回给server层。server层拿到id后，判断是不可能为空的，就按行累加。
3、对于count(1)来说，InnoDB引擎遍历整张表，但不取值。server层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。
4、对于count(字段) 来说：
——如果这个“字段”是定义为not null的话，一行行地从记录里面读出这个字段，判断不能为 null，按行累加；
——如果这个“字段”定义允许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。
5、count(）并不会把全部字段取出来，而是专门做了优化，不取值。count()肯定不是 null，按行累加。

按照效率排序的话，按照效率排序的话，count(字段)

VI、分析性能差别原则：

1、server层要什么就给什么；
2、InnoDB只给必要的值；
3、现在的优化器只优化了count(*) 的语义为“取行数”，其他“显而易见”的优化并没有做。

VII、复习-InnoDB特点

事务支持: redolog持久性，undolog原子性，mvcc+锁隔离级别。
并发：行锁而不是简单的表级锁。
数据安全：数据要持久化到磁盘