如果需要存储大量的URL并需要根据URL进行搜索查找。如果使用B-Tree 来存储URL，存储的内容就会很大，因为URL本身都很长。正常情况下会有如下查询：
在原版的基础上做了一下修正：增加1st在线支付功能与论坛用户数据结合，vip也可与论坛相关，增加互动性vip会员的全面修正评论没有提交正文的问题特价商品的调用连接问题删掉了2个木马文件去掉了一个后门补了SQL注入补了一个过滤漏洞浮动价不能删除的问题不能够搜索问题收藏时放入购物车时出错点放入购物车弹出2个窗口修正定单不能删除问题VIP出错问题主题添加问题商家注册页导航连接问题添加了导航FLASH源文
SELECT id FROM url WHERE url="http://www.baidu.com";
若删除原来URL上的索引，而新增一个被索引的url_crc列，使用CRC32做hash ，就可以用下面的方式查询：
SELECT id FROM url WHERE url='http://www.baidu.com' AND rul_crc=CRC32('http://www.baidu.com');
这样做性能非常高，因为MySQL 优化器会使用这个选择性很高而体积很小的基于url_crc列的索引来完成查找。即使有多个相同的索引值，查找任然很快，只需要根据hash值做快速的整数比较就能找到索引条目，然后一一返回对应的行。另外一种方式就是对完整的URL字符串做索引，那样会非常慢。
这样实现的缺陷是需要维护hash值。可以手动维护，可以触发器实现。如果采用这种方式，记住，不要使用SHA1()和MD5（）作为哈希函数。因为这两个函数计算出来的hash值时非常长的字符串，会浪费更大的空间，比较时也会更慢。SHA1()和MD5（）是强加密函数，设计目标是最大限度的消除冲突，蛋这里并不需要这样搞的要求。简单hash函数的冲突在一个可以接受的范围，同事有能提供更好的性能。
如果数据表非常大，CRC32()会出现大量的hash冲突，则可以考虑自己实现一个简单的64位hash函数。这个自定义的函数要返回整数，而不是字符串。一个简单的办法可以使用MD5()函数返回值的一部分来作为自定义hash函数。这肯能比自己写一个hash算法的性能要差，不过这样实现最简单。
SELECT CONV(RIGHT(MD5('http://www.baidu.com'),16),16,10) AS HASH64.
处理hash冲突。当使用hash索引进行查询的时候，必须在WHERE子句中包含常量值：
SELECT id from url WHERE url=crc32('http://www.baidu.com') AND url='http://www.baidu.com';
一旦出现hash冲突，另一个字符串的hash值也恰好是相同的，则下面的语句是无法正确工作的：
SELECT id from url WHERE url=crc32('http://www.baidu.com')；
因为所谓的‘生日悖论’ 出现hash冲突的概率的增长率可能比想象的要快的多，CRC32()返回的是32位整数，当索引有9.3W条记录时，出现冲突的概率是1%。例如，我们将'/usr/share/dic/words' 中的词倒数数据表，并进行crc32（）计算，最后会有98569行。这就已经出现一次hash冲突了。要避免hash冲突问题，必须在WHERE 条件中带入hahs值和对应的列值。如果不是想查询具体的值，例如只是统计记录数（不精确的），则可以不带入列值，直接使用crc32（）的hash值查询即可。还可以使用FNV64()函数作为hash函数，hash值为64位，速度非常快，且冲突比crc32（）要少很多。
