由于我们有一个使用投影的事件源系统，我们经常需要查询我们的事件存储以获取大量实体以(重新)构建我们的状态。 这是通过以下方式完成的:
1.在PartitionKey、RowKey上查询实体，偶尔进行额外过滤
2.处理结果段
3.重复此操作直到 continuationtoken== null
由 Azure Functions (V2)、Windows.Azure.Storage 9.3.1 运行。
我们遇到的问题是 ExecuteQuerySegmentedAsync 返回的段的大小从大约 200~ 到 700~ 个实体不等。我能够通过仅对 PartitionKey 进行简单查询来重现这一点，而无需额外的过滤。见:
文档指出 ExecuteQuerySegmentedAsync 最多可以返回 1k 个实体。关于为什么我们没有达到这个数字有什么想法吗？它将(有望)显着提高性能。
更新:未达到 5 秒的最大查询时间，获取一个段大约需要 200-300 毫秒。
最佳答案
Documentation states ExecuteQuerySegmentedAsync could return up to 1k of entities. Any ideas as to why we are not hitting that number?
针对表的每个查询最多允许执行 5 秒。在这 5 秒过去后，表服务将返回它能够根据查询找到的尽可能多的实体(最多 1000 个实体)。很可能在那 5 秒内没有找到任何实体，在这种情况下，它将返回零个带有延续标记的实体。
从这里link :
A query against the Table service may return a maximum of 1,000 entities at one time and may execute for a maximum of five seconds. If the result set contains more than 1,000 entities, if the query did not complete within five seconds, or if the query crosses the partition boundary, the response includes custom headers containing a set of continuation tokens. The continuation tokens may be used to construct a subsequent request for the next page of data. For more information about continuation tokens, see Query Timeout and Pagination.
关于c# - 为什么 CloudTable.ExecuteQuerySegmentedAsync 只返回最大 1k 实体的一小部分？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55576842/