每个人都警告不要查询 Azure 表存储 (ATS) 中的 RowKey 或 PartitionKey 以外的任何内容，以免被迫进行表扫描。有一段时间，当我需要查询其他内容时，这使我无法尝试提出完全正确的 PK 和 RK 并在其他表中创建伪二级索引。
但是，我突然想到，当我认为合适的时候，我通常会在 SQL Server 中进行表扫描。
所以问题就变成了，我能以多快的速度对 Azure 表进行表扫描。这是一个以实体/秒为单位的常数，还是取决于记录大小等。如果您想要一个响应式应用程序，是否有一些经验法则来说明有多少记录太多而无法进行表扫描？
表扫描的问题与跨越分区边界有关。您保证的性能级别是在分区级别明确设置的。因此，当您运行全表扫描时，它 a) 效率不高，b) 没有任何性能保证。这是因为分区本身设置在单独的存储节点上，当您运行跨分区扫描时，您可能会消耗大量资源（同时占用多个节点）。
我相信，跨越这些边界的效果也会产生延续令牌，这需要额外的往返存储来检索结果。这会导致性能下降，以及事务计数（以及随后的成本）增加。
如果您跨越的分区/节点数量相当少，您可能不会注意到任何问题。
但请不要引用我的话。我不是 Azure 存储方面的专家。它实际上是我最不了解的 Azure 领域。:P
我认为布伦特原油是 100% 的，但如果您仍然想尝试一下，我只能建议您进行一些测试以了解自己。尝试在查询中包含 partitionKey 以防止交叉分区，因为归根结底这是性能杀手。
Azure 表未针对表扫描进行优化。对于长时间运行的后台作业，扫描表格可能是可以接受的，但是当需要快速响应时我不会这样做。对于任何合理大小的表，您必须在查询到达分区边界或获得 1k 个结果时处理延续令牌。
Azure 存储团队有一篇很棒的文章解释了可伸缩性目标。单个表分区的吞吐量目标是 500 个实体/秒。存储帐户的总体目标是 5,000 个事务/秒。
答案是分页。将top_size-- max number of results or records in result -- 与next_partition_key和next_row_key延续标记一起使用。这在性能上产生了显着的甚至阶乘差异。一方面，您的结果在统计上更有可能来自单个分区。简单的结果表明，集合是按分区继续键而不是行继续键分组的。
换句话说，您还需要考虑您的 UI 或系统输出。不要费心返回超过 10 到 20 个结果，最多 50 个。用户可能不会再使用或检查。
听起来很愚蠢。在 Google 上搜索“dog”并注意搜索只返回 10 个项目。不再。如果您费心点击“继续”，接下来的记录对您有用。研究证明，几乎没有用户冒险超出第一页。
select（返回键值的子集）可能会有所不同；例如，使用select="PartitionKey,RowKey"或'Name'您需要的任何最小值。
“我相信，跨越这些边界的效果也会导致延续令牌，这需要额外的往返存储来检索结果。这会导致性能降低，以及事务计数（以及随后的成本）的增加。”
...有点不正确。使用延续令牌不是因为跨越边界，而是因为 azure 表允许不超过 1000 个结果；因此，这两个延续标记用于下一组。默认的 top_size 基本上是 1000。
为了您的观赏乐趣，这里是来自 azure python api 的查询实体的描述。其他的也差不多。
'''
Get entities in a table; includes the $filter and $select options.
table_name: Table to query.
filter:
Optional. Filter as described at
http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx
select: Optional. Property names to select from the entities.
top: Optional. Maximum number of entities to return.
next_partition_key:
Optional. When top is used, the next partition key is stored in
result.x_ms_continuation['NextPartitionKey']
next_row_key:
Optional. When top is used, the next partition key is stored in
result.x_ms_continuation['NextRowKey']
'''