我有一个典型的场景，消费者调用Azure Function(EP1((同步(，然后根据Azure Function API的输入参数查询Azure表存储(具有500万条记录(。Azure表存储具有以下列：
- 订单号(增量(
- IsConfirmed(可以具有值Y或N(
- 订单类型(最多可以有6种类型(
- 订单日期
- 订单详细信息
- UUID
现在，当消费者进行查询时，通常会使用订单号进行搜索，并期望得到响应的是订单日期和订单详细信息以及订单号。
为此，我们选择了：
- 分区密钥：IsConfirmed+订单类型
- 行关键字：UUID
现在，对于500万条记录的搜索，由于分区键类型的原因，搜索分区通常会遇到300多万条记录(最多订单的IsConfirmed为Y，type of Order是六种类型中的特定一种(，表查询需要5分钟以上的时间。因此，消费者通常超时，因为在消费者端配置的等待时间为60秒。
因此，寻求如何有效地做到这一点的建议。
- 我们可以选择分区键作为Order Number(但这将创建500万个分区(还是Order Number+IsConfirmed+TypeofOrder的组合
- 我们的是一个编写量很大的Java应用程序，而READ发生的次数要少得多
++++++更新++++++++++
正如Gaurav在回答中所建议的那样，在将orderid作为分区键之后，查询将按预期工作。
现在，这带来了下一个问题——我们确实有其他API查询，其中订单数据和类型仅用作输入搜索条件。
由于这与分区键不匹配，因此在第二种类型的查询中，它基本上进行了一次完整的扫描，消费者再次超时。
那么，处理这些类型的查询的设计应该是什么呢。。Azure文档表示，创建一个单独的表，其中订单类型+订单日期成为分区键。然而，这意味着，无论何时写入表，我们都必须同时写入两个表(一个表的orderid作为部分键，另一个表为订单日期+类型作为部分键(。
我们可以选择分区键作为订单号吗(但这将创建5百万个分区(或Order的组合编号+已确认+订单类型？
您当然可以选择分区键作为订单号，因为拥有大量分区并没有错。但是，请记住分区键值是字符串类型的。你可能想做的是用一些字符(比如0(填充你的订单号，这样你的所有订单都是相同的长度。
在这种情况下，我实际上建议您将行键保持为空。
您可能还需要考虑根据查询需求，使用不同的分区键/行键组合存储相同数据的多个副本。例如，如果要按订单日期进行查询，则可能需要制作另一个以订单日期为分区键的数据副本。
一般来说，建议您执行点查询(查询包括分区键和行键(。下一个最好的选择是按分区键进行查询(您希望保持分区键中的数据较小，这样就不会进行分区扫描(。所有其他选项都会导致完整的表扫描，这根本不是建议的。
您可能会发现此链接很有用：https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-guidelines.