我的索引类似于60-100万个文档。我们几乎总是在外键id上查询这些文档（除了其他过滤器查询和字段查询等），以将查询范围限定到特定的父对象。
所以，例如：/solr/q=*:*&fq=parent_id_s:42
是的，_s表示目前这是solr.StrField字段类型。
我的问题是：我应该将其更改为TrieIntField吗？这会加快表现吗？如果是这样，那么理想的precisionStep和positionIncrementGap值是什么，因为我知道我将始终查询单个特定值，并且parent_id的基数是在10,000-100,000（最大）数量级？
编辑aditional详细信息（来自以下答案的评论）： 我们的系统使用方式，结果是我们最终连续使用相同的fq进行许多查询。当填充缓存时，系统会快速运行。当缓存因提交而被转储时，此查询（即使只有此fq的测试用例）最多可能需要20秒。所以我试图弄清楚如何加快填充缓存的初始查询。
第二次编辑：
我道歉，经过进一步的测试后发现，只有当还有facet字段被返回时才会发生上述不良表现（例如&facet=true&facet.field=resolved_facet_facet之类的东西）。有十几个这样的字段，有时候查询需要20-30秒，但只有一个新的搜索者。填充缓存时即刻。所以我的问题可能是facet字段，而不是parent_id字段。
答案 0 :(得分：4)
TrieIntField针对范围查询进行了优化。由于您只搜索特定值，因此您的字段类型是最佳的。
你看过autowarming查询了吗？每当创建一个新的IndexSearcher时（例如在启动时，在索引提交上），它们就会运行，这样它就可以使用一些缓存了。根据您的要求，您还可以将useColdSearcher标志设置为true，以便新的搜索器仅在缓存已加热时可用。有关详细信息，请查看此处：https://cwiki.apache.org/confluence/display/solr/Query+Settings+in+SolrConfig#QuerySettingsinSolrConfig-Query-RelatedListeners
答案 1 :(得分：2)
听起来你可能没有从过滤器缓存结果集中获得太多好处。过滤器的一个更重要的功能是它们缓存其结果集。这使得某个过滤器的第一次运行在构建缓存时花费的时间更长，但后续使用相同的过滤器要快得多。
根据您所描述的基数，您可能只是浪费周期并污染过滤器缓存，通过构建缓存而不使用它们。您可以turn off caching过滤查询，例如：
/solr/q=*:*&fq={!cache=false}parent_id_s:42
答案 2 :(得分：0)
我也认为过滤查询在这种情况下没有帮助。
q=parent_id_s:42是按术语"parent_id_s:42"查询索引并获取一组文档ID。由于帖子（文档ID）是由术语索引的，并且假设你有足够的内存来保存它（在JVM或OS缓存中），那么这个查找应该非常快。
假设过滤器缓存已经预热，并且您有100％的命中率，以下哪一项更快？
q=parent_id_s:42
fq=parent_id_s:42
我认为他们非常接近。但我可能是错的。有谁知道？有没有知道对此进行性能测试？