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