标签：排序 开发 为什么 文章 asc type 交易 优化 参数
原文:Mysql性能优化：为什么你的count(*)这么慢？
count函数是怎样处理的？count函数有不同的实现方式。MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高（没有where查询条件）。InnoDB引擎并没有直接将总数存在磁盘上，在执行count(*)函数的时候需要一行一行的将数据读出来，然后累计总数。说到InnoDB相信读者总会想到其支持事务的特性，事务具有隔离性，如果将总数存起来，怎么保证各个事务之间的总数的一致性呢？不明白的看图
事务A和事务B中的count(*)的执行结果是不同的，因此InnoDB引擎在每个事务中返回多少行是不确定的，只能一行一行的读出来用来判断总数。
InnoDB对于如何提升count(*)的查询效率，网上有多种解决办法，这里主要介绍三种，并分析可行性。show table status这个命令能够很快的查询出数据库中每个表的行数，但是真的能够替代count(*)吗？40%-50%。这种方法也是最容易想到的，增加一行就+1，删除一行就-1，并且缓存系统读取也是很快，既简单又方便的为什么不用？
缓存系统和Mysql是两个系统，比如redis和Mysql这两个是典型的比较。两个系统最难的就是在高并发下无法保证数据的一致性。 
通过上面两张图，无论是redis计数+1还是insert into user先执行，最终都会导致数据在逻辑上的不一致。第一张图会出现redis计数少了，第二张图虽然计数正确了但是并没有查询出插入的那一行数据。
在并发系统里面，我们是无法精确控制不同线程的执行时刻的，因为存在图中的这种操作序列，所以，我们说即使Redis正常工作，这个计数值还是逻辑上不精确的。
通过缓存系统保存的分析得知了使用缓存无法保证数据在逻辑上的一致性，因此我们想到了直接使用数据库来保存，有了「事务」的支持，也就保证了数据的一致性了。
如何使用呢？很简单，直接将计数保存在一张表中（table_name,total）。
至于执行的逻辑只需要将缓存系统中redis计数+1改成total字段+1即可，如下图： 
由于在同一个事务中，保证了数据在逻辑上的一致性。
count()是一个聚合函数，对于返回的结果集，一行行地判断，如果count函数的参数不是NULL，累计值就加1，否则不加。最后返回累计值。count的用法有多种，分别是count(*)、count(字段)、count(1)、count(主键id)。那么多种用法，到底有什么差别呢？当然，「前提是没有where条件语句」。count(id)：InnoDB引擎会遍历整张表，把每一行的id值都取出来，返回给server层。server层拿到id后，判断是不可能为空的，就按行累加。count(1)：InnoDB引擎遍历整张表，但不取值。server层对于返回的每一行，放一个数字1进去，判断是不可能为空的，按行累加。count(字段)：count(*)：不会把全部字段取出来，而是专门做了优化，不取值。count(*)肯定不是null，按行累加。
not null的话，一行行地从记录里面读出这个字段，判断不能为null，按行累加；null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。count(字段)<count(主键id)<count(1)≈count(*)，所以建议读者，尽量使用count(*)。」count(id)不是走的索引吗，为什么查询效率和其他的差不多呢？陈某在这里解释一下，虽然走的索引，但是还是要一行一行的扫描才能统计出来总数。MyISAM表虽然count(*)很快，但是不支持事务；show table status命令虽然返回很快，但是不准确；InnoDB直接count(*)会遍历全表(没有where条件)，虽然结果准确，但会导致性能问题。更新计数+1,还是先插入数据。即是先update total+=1还是先insert into。标签：排序 开发 为什么 文章 asc type 交易 优化 参数
原文地址：https://www.cnblogs.com/lonelyxmas/p/12630080.html
