Mysql深入——7

count（*）为什么这么慢？？？

在不同的MySQL引擎中，count（*）有不同的实现方式，MyISAM引擎将一个表的总行存在了磁盘上，需要的时候会直接返回，但InnoDB需要遍历全表累加计算。这里说的是没有加where条件的，若加了where限制条件，MyISAM也会变慢。

那么为什么InnoDB不喝MyISAM一样，把总数存起来呢？

因为InnoDB是并发控制的，无法准确返回有多少行，比如说线程A启动事务查询总行数，线程B启动事务插入一条数据后，查询总行数，线程C启动一个单独语句，插入一条记录后，查询总行数，这个三个线程同时启动，因为提交事务的时间不一样，所以查询出来返回的行数也是不同的。

InnoDB是索引组织表，主键的叶子节点是数据，普通索引的叶子节点是主键值，所以普通索引的树是比主键树小的，所以在保证逻辑正确的前提下，尽量减小扫描的数据量是设计数据库的通用法则之一。

使用show table status来解决

在InnoDB，存在这show table status这个命令，这个命令会返回一个table_rows用于返回有多少行，虽然这样很快，但是返回结果是及其不准确的，误差40%-50%之间，它也使用了采样估算的方法，所以是不准确的，这个命令返回的行数数据也不推荐使用。

使用缓存系统来解决

将Reids放在缓存系统当中，当被添加入一行的时候，Reids+1，减少一行的时候，相应的Reids-1。这种情况下，操作都很快，但是存在缓存系统可能会失去更新的问题。

因为Reids不能永久保存下来，所以得将它找个地方把这个值永久的保存下来，我们若在数据行中添加了一行，Reids异常重启了，将这个操作丢失了，我们就得单独去数据页中进行全表遍历得到count的值赋给Reids，因为异常重启不是经常出现的现象，所以偶尔一次的全表遍历也是可以接受的。

我们抛开异常重启不谈，它在逻辑上也存在着问题，比如

1. A线程插入数据R，B线程读Redis数，查询最近100条记录，线程A将Redis加1

2.线程A将Redis加1，B线程读Redis数，查询最近100条记录，线程A插入数据R

这里的两种情况是线程A也就是Reids的操作顺序，如果是1，查询出有新纪录但是Redis没有加1，第二种虽然加一了，但是查询不出新的记录，这里虽然Reids可以正常运行下去，但是逻辑上是存在着问题的

使用数据库来解决

我们将计数直接放到数据库当中一张单独的表中，首先这解决了系统崩溃数据丢失的问题，因为InnoDB是支持崩溃后恢复数据的。那么我们如何解决上面的逻辑问题，其实答案很简单，使用事务来解决，上面我们使用缓存系统是因为两个线程提交的时间不同，导致了最后的结果不同，那么我们现在将计数表加1，不提交这个事务，然后开启下一个事务，即为读计数表，查询100条记录，因为前一个事务并没有提交，所以读到的计数表并不会变化，而且查询到的100条记录中也没有新的记录，我们将后面这个事务提交，然后再回到前一个事务中，对表进行插入操作后提交第一个事务，这样逻辑上就是一致的了。