當使用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對結果的一致性有直接影響，但實際上這只是一個副作用。