位图（BitMap）索引

　　前段时间听同事分享，偶尔讲起Oracle数据库的位图索引，顿时大感兴趣。说来惭愧，在这之前对位图索引一无所知，因此趁此机会写篇博文介绍下位图索引。

1. 案例

　　有张表名为table的表，由三列组成，分别是姓名、性别和婚姻状况，其中性别只有男和女两项，婚姻状况由已婚、未婚、离婚这三项，该表共有100w个记录。现在有这样的查询： select * from table where Gender=‘男’ and Marital=“未婚”;

姓名(Name)	性别(Gender)	婚姻状况(Marital)
张三	男	已婚
李四	女	已婚
王五	男	未婚
赵六	女	离婚
孙七	女	未婚
...	...	...

1）不使用索引

　　不使用索引时，数据库只能一行行扫描所有记录，然后判断该记录是否满足查询条件。

2）B树索引

　　对于性别，可取值的范围只有'男','女'，并且男和女可能各站该表的50%的数据，这时添加B树索引还是需要取出一半的数据，因此完全没有必要。相反，如果某个字段的取值范围很广，几乎没有重复，比如身份证号，此时使用B树索引较为合适。事实上，当取出的行数据占用表中大部分的数据时，即使添加了B树索引，数据库如oracle、mysql也不会使用B树索引，很有可能还是一行行全部扫描。

2. 位图索引出马

如果用户查询的列的基数非常的小，即只有的几个固定值，如性别、婚姻状况、行政区等等。要为这些基数值比较小的列建索引，就需要建立位图索引。

对于性别这个列，位图索引形成两个向量，男向量为10100...，向量的每一位表示该行是否是男，如果是则位1，否为0，同理，女向量位01011。

RowId	1	2	3	4	5	...
男	1	0	1	0	0
女	0	1	0	1	1

　　对于婚姻状况这一列，位图索引生成三个向量，已婚为11000...，未婚为00100...，离婚为00010...。

RowId	1	2	3	4	5	...
已婚	1	1	0	0	0
未婚	0	0	1	0	1
离婚	0	0	0	1	0

　　当我们使用查询语句“select * from table where Gender=‘男’ and Marital=“未婚”;”的时候首先取出男向量10100...，然后取出未婚向量00100...，将两个向量做and操作，这时生成新向量00100...，可以发现第三位为1，表示该表的第三行数据就是我们需要查询的结果。

RowId	1	2	3	4	5
男	1	0	1	0	0
and
未婚	0	0	1	0	1
结果	0	0	1	0	0

3.位图索引的适用条件

　　上面讲了，位图索引适合只有几个固定值的列，如性别、婚姻状况、行政区等等，而身份证号这种类型不适合用位图索引。

　　此外，位图索引适合静态数据，而不适合索引频繁更新的列。举个例子，有这样一个字段busy，记录各个机器的繁忙与否，当机器忙碌时，busy为1，当机器不忙碌时，busy为0。

　　这个时候有人会说使用位图索引，因为busy只有两个值。好，我们使用位图索引索引busy字段！假设用户A使用update更新某个机器的busy值，比如update table set table.busy=1 where rowid=100;，但还没有commit，而用户B也使用update更新另一个机器的busy值，update table set table.busy=1 where rowid=12; 这个时候用户B怎么也更新不了，需要等待用户A commit。

　　原因：用户A更新了某个机器的busy值为1，会导致所有busy为1的机器的位图向量发生改变，因此数据库会将busy＝1的所有行锁定，只有commit之后才解锁。

以下内容转载自：https://blog.csdn.net/pzqingchong/article/details/50971854

当前测试的版本是Mysql 5.5.25只有BTree和Hash两种索引类型，默认为BTree。Oracle或其他类型数据库中会有Bitmap索引（位图索引），这里作为比较也一起提供。

BTree索引

BTree（多路搜索树，并不是二叉的）是一种常见的数据结构。使用BTree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。按照翻译，B 通常认为是Balance的简称。这个数据结构一般用于数据库的索引，综合效率较高。——百度百科

不适合：

单列索引的列不能包含null的记录，复合索引的各个列不能包含同时为null的记录，否则会全表扫描；
不适合键值较少的列（重复数据较多的列）；
前导模糊查询不能利用索引(like '%XX'或者like '%XX%')

Hash散列索引

Hash散列索引是根据HASH算法来构建的索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。

适合：

精确查找非常快（包括= <> 和in），其检索效率非常高，索引的检索可以一次定位，不像BTree 索引需要从根节点到枝节点，所以 Hash 索引的查询效率要远高于 B-Tree 索引。

不适合：

不适合模糊查询和范围查询（包括like，>，<，between……and等），由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样；
不适合排序，数据库无法利用索引的数据来提升排序性能，同样是因为Hash值的大小不确定；
复合索引不能利用部分索引字段查询，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
同样不适合键值较少的列（重复值较多的列）；

Bitmap位图索引

就是用位图表示的索引，对列的每个键值建立一个位图。相对于BTree索引，占用的空间非常小，创建和使用非常快。位图索引由于只存储键值的起止Rowid和位图,占用的空间非常少。如test表中有state这样一列，10行数据如下：

10 20 30 20 10 30 10 30 20 30

那么会建立三个位图，如下：

BLOCK1    KEY=10  1    0    0    0    1    0    1    0    0    0
BLOCK2    KEY=20  1    0    0    0    1    0    1    0    0    0
BLOCK3    KEY=30  1    0    0    0    1    0    1    0    0    0

适合