BerkeleyDB的cache可以采用Hash和BTree两种索引方式，今天测试了这两种方式的存取速度，测试方法是：向bdb中写100万条记录，key是1至100万的数字编号，value分别是32、64、128、256字节的字符串，然后再顺序查询这100万条记录，分别统计写和读的时间，其中bdb版本为4.2。
当cache开到1G大小时，数据如下（其中大小单位为字节，时间单位为秒）：
| Cache为1G时 |
| value大小（字节） |
Hash写时间 |
Hash读时间 |
BTree写时间 |
BTree读时间 |
| 32 |
12 |
6 |
4 |
3 |
| 64 |
8 |
4 |
4 |
3 |
| 128 |
7 |
4 |
5 |
3 |
| 256 |
7 |
4 |
6 |
3 |
由于cache非常大，几乎所有的数据都可以放在里面，所以两种索引方式的存取效率基本一样。
如果把cache改为32M，测试结果又如下：
| Cache为32M时 |
| value大小（字节） |
Hash写时间 |
Hash读时间 |
BTree写时间 |
BTree读时间 |
| 32 |
11 |
6 |
5 |
39 |
| 64 |
205 |
62 |
17 |
50 |
| 128 |
缺 |
缺 |
44 |
42 |
| 256 |
缺 |
缺 |
186 |
51 |
其中“缺”字表示测试无法进行，因为当数据太大时，用Hash索引运行bdb几乎把机器搞死，我不得不中断测试。这组测试看得出：如果使用BTree，随着数据的翻倍，写的时间也近乎翻倍，但读的时间非常稳定，对于数据量大、写少读多的应用（比如bbs、图片服务等）应该尽量使用BTree索引。
总的来看，BerkeleyDB的Hash索引表现古怪，只在小cache小数据量的情况下查询速度快于BTree，可现在哪会有这种情况？还是用BTree索引保险一些。
