当使用谷歌应用引擎搜索 API 时，如果我们有一个查询返回一个大的结果集（>1000），并且需要使用游标迭代来收集整个结果集，如果返回的文档我们会得到不确定的结果number_found_accuracy 小于我们的结果大小。
换句话说，相同的查询运行了两次，通过游标收集所有文档，不会返回相同的文档，除非我们的 number_found_accuracy 高于结果大小（例如，使用最大值 10000）。只有这样，我们才能始终获得相同的文件。
我们对 number_found_accuracy 应该如何工作的理解是它只会影响 number_found 估计。我们假设如果您使用游标来获取所有结果，您将能够获得与运行一个大型查询相同的结果。
我们是否误解了 number_found_accuracy 或游标的使用，还是我们发现了一个错误？
您对 number_found_accuracy 的理解是正确的。我认为您观察到的行为是复制查询故障转移与指定 number_found_accuracy 的查询如何影响使用延续令牌的未来查询之间令人惊讶的相互作用。
当您使用 Search API 索引文档时，我们使用与 High Replication Datastore（即Megastore ）相同的机制将它们存储在几个不同的副本中。这些文档在每个副本上生效的速度取决于许多因素。它通常是立即的，但如果您对单个 (index, namespace) 对进行批量写入，延迟可能会变得更长。
可以在这些副本中的任何一个上执行搜索。我们甚至可能会在与原始搜索不同的副本上运行使用延续令牌的搜索。如果原始副本和/或延续副本正在赶上他们的索引工作，他们可能有不同的活动文档集。它会“最终”变得一致，但并不总是立竿见影。
如果您在查询中指定 number_found_accuracy，我们必须运行大部分查询，就好像我们要返回 number_found_accuracy 结果一样。我们特别需要进一步阅读发布列表以查找和计算匹配的文档。读取发布列表会导致其关联的文件块被插入到各种缓存中。
反过来，当您使用光标进行搜索时，我们将能够在我们用于原始搜索的同一副本上更快地阅读文档。因此，您不太可能将继续搜索故障转移到可能尚未完成对同一组文档的索引的不同副本。我认为您观察到的不一致结果是这种延续查询故障转移的结果。
总之，将 number_found_accuracy 设置为较大的值可以有效地预热该副本的缓存。因此，它几乎肯定会是继续搜索的最快副本。面对试图赶上索引的副本，这会让人觉得 number_found_accuracy 对结果的一致性有直接影响，但实际上它只是一个副作用。