Bitmap 索引 vs. B-tree 索引：如何选择以及何时使用？——1-5

——理解适当使用每个索引对性能的影响

本文内容

比较索引
演示环境
步骤 1A（TEST_NORMAL 表 EMPNO 列创建 Bitmap 索引，执行等值查询）
步骤 1B（TEST_NORMAL 表 EMPNO 列创建 B-tree 索引，执行等值查询）
步骤 2A（TEST_RANDOM 表 EMPNO 列创建 Bitmap 索引，执行等值查询）
步骤 2B（TEST_RANDOM 表 EMPNO 列创建 B-tree 索引，执行等值查询）

一般观点认为，Bitmap 索引更适合具有较低不重复（distinct）值的列——如性别、状态和关系。然而，这个假设并不完全。实际中，Bitmap 索引对系统有个建议，数据不会被很多并发系统频繁更新（不希望数据被系统频繁更新）。事实上，我想说，一个具有 100% 唯一值（unique values）列（该列可以作为主键）上的 Bitmap 索引具有与 B-tree 索引同样的效率。

本文，我将提供一些例子和执行计划，这些例子有两种索引类型，以及低基数列和高基数列。这些例子将帮助 DBA 理解 Bitmap 索引的使用并不是基数依赖，而是应用依赖。

另外，本文是基于一篇 2005 年的英文文章，表格数据是原文的，除此之外，是自己在本机测试的结果。

有意思的是，英文表格中的逻辑 IO 和物理 IO 数据。逻辑 IO 数据与本文测试结果一致，而物理 IO 基本都不一样，英文中大都不为 0，而在测试我的中，几乎都为 0。我的理解是，尽管一百万的数据，但其实总体量很小，而且跟硬件发展有也有很大关系。

英文原文下载

比较索引

在唯一值列上使用 Bitmap 索引有很多不利之处——其中一个就是需要足够的空间（Oracle 也不推荐这样做）。然而，Bitmap 索引的大小依赖索引列的基数和数据分布。因此，GENDER 列的 Bitmap 索引要比其 B-tree 索引小。相反，EMPNO 列（可作为主键列）的 Bitmap 索引要比其 B-tree 索引大很多。但因为，访问决策支持系统（decision-support systems，DSS）的用户比访问事务处理系统（transaction-processing，OLTP）要少很多（毕竟只有高层领导才会用）。对这些应用程序来说，资源不是问题。

为了说明这个观点，我创建两个表，TEST_NORMAL 和 TEST_RANDOM，插入 1000000 条数据。插入 TEST_NORMAL 表的数据是按顺序的，而 TEST_RANDOM 表的数据是根据 TEST_NORMAL 表数据随机追加的。

table test_normal (empno number(10), ename varchar2(30), sal number(10));