solr filter query的误用

出处：http://sling2007.blog.163.com/blog/static/84732713201310531215142/

数据小的时候没发现问题，随着数据增多，最近在用solr的filter query的时候，发现速度很慢，而不用filterquery则很快。也就是说单单关键词查询是很快的，加上filterquery就慢了。。。
其实普通的query是影响得分的主要查询，filter query则是执行完query后，在query结果基础上的进一步过滤。这是可以用缓存等，以提高效率。

分析原因，不是fq慢了，而是fp的字段设置有误。

解决办法如下：
1、filterquery的字段用precisionStep=6，建立索引。这是一种trie结构，原理是http://sling2007.blog.163.com/blog/static/8473271320139314624853/
2、开启fq缓存。
这两个办法都比较重要，都要用上才好。


具体原因，转了两篇文章如下：
【转】http://blog.sina.com.cn/s/blog_a584e4ca01017l8w.html
【转】http://wenku.it168.com/d_001196668.shtml

solr filter query的误用 在我整理solr SolrIndexSearcher性能问题分析的时候，我就在想，我是不是误用了SolrIndexSearcher，才出现我所以为的性能问题。当我想到其实现特点，我恍惚确定确实是这样的，根源就是我误用filter query。上篇文章暂且放下，这篇做个补充。如我上文所述，fq=fid:1这个条件匹配的文档数会很多，不过，如果开启了filter cache，那么只会在第一次调用时慢些，后续的调用都会命中cache而提升速度，而通过query预热是可以解决初次调用的低速问题。所以，如果要使用filter query，就要开启filter cache，并确保filter cache能容纳所有的filter query。这也需要对应用的查询特点做好分析。以fq=atm:[int_time1 TO int_time2]为例，我之前是将它放到filter query中，不过因为每次查询的int_time1和int_time2都几乎不相同，使得总不能命中filter cache，严重影响了查询性能。另一方面，我在做压力测试时也发现，当filter query结果充满了filter cache，最终使得程序内存耗尽。对filter query的使用，还有个注意点，就是solr是按每个fq参数缓存结果的，所以fq=fid:1、fq=fid:2、fq=(fid:1 OR fid:2)是3个缓存项。而像atm:[int_time1 TO int_time2]这样的范围查询，如果个数不是可枚举的，就不要使用它作为fq。