什么是Solr查询结果缓存工作机制？

我试图理解Solr查询结果缓存是存储“完整查询的结果”还是“主查询结果”

q=国家：美国&fq=州：CA。假设主查询匹配了100个文档。过滤器对100个文档起作用，结果是10个文档。查询缓存会保存100个文档ID还是仅保存10个文档ID。意思是完整的结果还是仅仅是主要的查询结果？因为上面的博客读到查询缓存将容纳100个文档。但是查询结果缓存代码显示，结果集缓存的键也包括过滤器。希望得到确认

---

我能有任何专业知识来证实这种行为吗？必须从源代码运行solr并在intellij中调试是一件痛苦的事情。

快速浏览一下，那篇文章令人困惑。如果更仔细的阅读能澄清问题，我会道歉

queryResultCache不存储整个结果集，它存储QueryResultWindowsSize（在solrconfig.xml中指定）。因此，如果您的查询匹配1000000个文档，并且QueryResultWindowsSize为50，那么对于此查询，此缓存中只存储50个文档ID（在您的示例中为10个）。设想一下，这是一个缓存，用于存储几页的ID，因此当用户点击“下一步”时，不必重新执行查询

在我的示例中，在&start+&rows超过50之前，不必重新执行查询。然后又有50个文档从&start开始在缓存中创建一个新条目。存储的文档尊重查询的所有内容。排序顺序、分数、FQ的应用开始等。在这个缓存中存储1M DOC ID是不现实的，尤其是当您认为完全相同的查询是罕见的，然后您必须保持排序列表1000000（在我的例子中），也称为“深度寻呼”问题。

本文还讨论了filterCache，它保存了整个结果集。但是，它只是一个以maxDocs/8为边界的位集，每个满足fq子句的文档都有一个on位。在我的示例中，此位集将设置1000000位，如果索引中有8M个文档，则大约为1兆字节（即maxDoc=8000000）。这是一个与queryResultCache截然不同的问题，因为不涉及排序，Lucene必须为每个文档打分。只要分数不为零，就稍微翻转一点，这会大大增加执行时间