|
一个大表的COUNT，究竟能有多快？除类似物化视图的做法，我们所能做到的极限能有多快？这不是一个真实的案例，而是根据笔者在网上发的一篇帖子整理而来。通过对一条SQL，采用多种方式持续优化过程，表明SQL优化的手段随着优化者掌握的技能增多，其可能存在的手段也在不断增多。 1、数据准备 2、全表扫描 全表扫描的代码如下（共用124秒，好慢呀）： 由上可知，全表扫描耗时较长。 3、主键索引 主键索引的代码如下： 通过引入索引，执行计划变成索引快速全扫描，因扫描块数较少，因此耗时也大大减少，共用33秒，快多了。 4、常数索引 常数索引的代码如下： 常数索引在存储密度上要高于普通字段索引，因此扫描块数更少，耗时也更少，共耗时29秒。 5、常数压缩索引 常数压缩索引的代码如下 索引压缩进一步减少了扫描规模，耗时缩减到27秒。 6、位图索引 位图索引不同于B树索引，其存储密度更高。这里是采用status字段，如果使用常数索引，其规模将更小。这种手段用时0.9秒，这是质的飞跃。 7、位图索引+并行 并行技术可以较快执行速度。一致性读有所增加，但并行还是能加快整体运行速度，这种手段耗时0.03秒，竟然又快了不少。 位图索引可以按很高密度存储数据，因此往往比B树索引小很多。前提是在基数比较小的情况下。 位图索引是保存空值的，因此可以在COUNT中利用。 众所周知，位图索引不太适合OLTP类型数据库。该实例仅为了测试展示 优化没有止境，对数据库了解越多，你能想到的方法就越多。 --本文节选自《SQL 优化最佳实践》第一章。 如何加入"云和恩墨大讲堂"微信群 |
|
|
