你真的会用索引吗？来看看COUNT(*)到底能有多快

作者简介

案例说明

一个大表的COUNT，究竟能有多快？除类似物化视图的做法，我们所能做到的极限能有多快？这不是一个真实的案例，而是根据笔者在网上发的一篇帖子整理而来。通过对一条SQL，采用多种方式持续优化过程，表明SQL优化的手段随着优化者掌握的技能增多，其可能存在的手段也在不断增多。

1、数据准备

2、全表扫描

全表扫描的代码如下（共用124秒，好慢呀）：

由上可知，全表扫描耗时较长。

3、主键索引

主键索引的代码如下：

通过引入索引，执行计划变成索引快速全扫描，因扫描块数较少，因此耗时也大大减少，共用33秒，快多了。

4、常数索引

常数索引的代码如下：

常数索引在存储密度上要高于普通字段索引，因此扫描块数更少，耗时也更少，共耗时29秒。

5、常数压缩索引

常数压缩索引的代码如下

索引压缩进一步减少了扫描规模，耗时缩减到27秒。

6、位图索引

位图索引不同于B树索引，其存储密度更高。这里是采用status字段，如果使用常数索引，其规模将更小。这种手段用时0.9秒，这是质的飞跃。

7、位图索引+并行

并行技术可以较快执行速度。一致性读有所增加，但并行还是能加快整体运行速度，这种手段耗时0.03秒，竟然又快了不少。

结论分析

位图索引可以按很高密度存储数据，因此往往比B树索引小很多。前提是在基数比较小的情况下。

位图索引是保存空值的，因此可以在COUNT中利用。

众所周知，位图索引不太适合OLTP类型数据库。该实例仅为了测试展示

案例启示

优化没有止境，对数据库了解越多，你能想到的方法就越多。