我有一个包含大约6千万到1亿个文档的索引。我们几乎总是基于外键ID查询这些文档(除了其他过滤查询和字段查询等)，以将查询范围限定在特定的父对象中。
例如：
我的问题是：我应该将其更改为TrieIntField吗？这样会加速性能吗？如果是的话，给定我知道我将始终查询单个特定值，并且该parent_id的基数处于10,000-100,000（最大）数量级，那么理想的precisionStep和positionIncrementGap值是什么？
附加细节编辑（来自下面答案的评论）：
我们系统的使用方式是，我们最终会连续使用相同的fq进行许多查询。当缓存被填充时，系统运行得非常快。当由于提交而导致缓存被清空时，这个查询（甚至只有这个fq的测试用例）可能需要长达20秒。因此，我正在尝试找出如何加速填充缓存的初始查询。
第二次编辑：
很抱歉，经过进一步测试，发现上述性能差的情况只发生在返回facets字段时（例如，
例如：
/solr/q=*:*&fq=parent_id_s:42
是的，这里的“_s”表示这是当前的solr.StrField字段类型。我的问题是：我应该将其更改为TrieIntField吗？这样会加速性能吗？如果是的话，给定我知道我将始终查询单个特定值，并且该parent_id的基数处于10,000-100,000（最大）数量级，那么理想的precisionStep和positionIncrementGap值是什么？
附加细节编辑（来自下面答案的评论）：
我们系统的使用方式是，我们最终会连续使用相同的fq进行许多查询。当缓存被填充时，系统运行得非常快。当由于提交而导致缓存被清空时，这个查询（甚至只有这个fq的测试用例）可能需要长达20秒。因此，我正在尝试找出如何加速填充缓存的初始查询。
第二次编辑：
很抱歉，经过进一步测试，发现上述性能差的情况只发生在返回facets字段时（例如，
&facet=true&facet.field=resolved_facet_facet）。有大约十几个这些字段时，查询有时需要20-30秒，但只有在新的搜索器中才会出现这种情况。当缓存被填充时，它是瞬间完成的。因此，也许我的问题在于facets字段，而不是parent_id字段。
facet.method = enum。似乎这是一个小的改进，但似乎打开并调整自动预热可能是我所能做的最好的事情... - Jeff Gran