使用查询按行键获取记录/记录有多好？让查询只检查行键是否有意义？我知道您可以结合 primarykey + rowkey 并获取特定记录，或者然后通过特定分区键获取所有记录（因此所有相关数据将快速返回）。
我猜如果您进行查找 rowkey 的查询，那么当您查询包含大量项目的表时性能会下降，因为它必须查看所有项目。
你们能说出一个用rowkey（单独）make's sens进行查询时的案例吗？我不是指检索到的结果，而是在发送到 azure storage 以返回项目的查询中。
【问题讨论】：
标签： azure-storage azure-table-storage
Azure 表存储（截至目前）构建了两个索引，它们是 PartitionKey 和 Rowkey，可以使查找更快/更快。仅当您有一个分区（或很少的分区）时，按行键查询才有意义。如果您有很多分区，并且您只需指定行键，它将必须查找所有分区。
例如，假设您将社会安全号码存储在表存储中。让我们看两个场景...
一个好的分区策略可能是将状态作为分区键。在您的查询中，如果您只是通过 PartitionKey='CA' & RowKey ='123456789' Azure 表存储知道要转到的分区以及该分区中的确切行。如果您的查询只是：RowKey = '123456789'，Azure 表存储必须扫描所有分区（50 个状态）才能找到匹配的 RowKey。
另一种策略可能是一个巨大的单个分区，其中行键作为社会安全号码。如果您的查询：RowKey = '123456789' 那么 Azure 表存储可以使用行键上的索引来快速查找值。由于只有一个分区，不属于查询一部分的 PartitionKey 不会减慢它（或至少不应该）。
另外请记住，Azure 表存储内部可以将分区放在不同的驱动器上，以针对大量使用进行优化。所以为有很多分区的大表指定partitionkey是比较理想的。
【讨论】：
正如 Bart Czernicki 也提到的，仅在查询中指定 Row Key 会导致全表扫描，因为服务器需要遍历表中的所有分区。请在How to get most out of Windows Azure Tables 文章（特别是“分区”部分）中找到有关此主题的更多信息。
【讨论】：