mysql数据库分析结果与结论_【数据库相关】mysql-select count (*) 总结

今天看到个帖子，select count (*) from table  这个语句有很多的说道儿，想了一下就一条普普通通，简单的不能再简单的查询语句能有什么说道儿？

继续往下看了帖子，发现这玩意真的是有点东西。

1.验证：

首先这个语句是平时查询数量的时候常用的语句，当数据量足够大的时候，这个语句就显现出来问题了。

故上项目中的数据库中找一个最大的表来进行验证。发现这个表用正常的建表，建主键的时候。执行这条语句所需的时间很长，长到我已经没有耐心等到他查询出来结果了。

2.分析

这条语句为什么会执行这么长时间？

当然这条语句肯定不能在进行优化了(本人没有再进行优化的能力了)，那为什么这个语句会执行这么长时间？看了帖子发现，是因为这个表的表结构中只有一条聚簇索引(本人理解：创建表的时候，主键自动生成的索引就叫聚簇索引)，而执行这条语句的时候，在InnoDB存储引擎中，count(*)函数是先从磁盘中读取表中的数据到内存缓冲区，然后扫描全表获得行记录数的。因此查询的时间固然长。

3.优化

那么这种情况该如何优化呢？

就要用到一个二级索引的概念了，二级索引也叫辅助索引，也就是除了聚簇索引以外的索引都叫辅助索引。辅助索引的每一行记录都包含每一行的主键列，索引指向主键，InnoDB使用这个主键查找聚簇索引中的行。

那么在表中加上二级索引后执行的效率如何呢？

效率是瞎眼可见的提升。

4.结论

当表中的数据量足够大的时候，最好要在表中添加一条辅助索引。