table{ padding:2px; border:1px solid #aaaaaa; border-collapse:collapse; } td{ padding:2px; border:1px solid #aaaaaa; border-collapse:collapse; }       当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索引保险一些。