问将点查询连接在一起时Azure表存储中的不可靠性能

EN

我在Azure表存储的性能方面遇到了一致的问题。我正在查询一个保存用户帐户的表。该表将userId存储在PartitionKey和RowKey中，因此我可以轻松地进行点查询。

我的问题是，在某些情况下，我需要在一个查询中检索多个用户。为了实现这一点，我有一个为我构建过滤器字符串的类。它的工作方式与问题无关，但这是输出的一个示例：

(PartitionKey eq '00540de6-dd2b-469f-8730-e7800e06ccc0' and RowKey eq '00540de6-dd2b-469f-8730-e7800e06ccc0') or 
(PartitionKey eq '02aa11b7-974a-4ee9-9a8e-5fc09970bb99' and RowKey eq '02aa11b7-974a-4ee9-9a8e-5fc09970bb99') or 
(PartitionKey eq '040aec50-ebcd-4e5d-8f58-82aea616bd82' and RowKey eq '040aec50-ebcd-4e5d-8f58-82aea616bd82') or 
// up to 22 more (25 total)

在第一次执行查询时，它需要很长的时间来执行，在2-5秒之间，并且缺少导致错误的数据。第二次运行时，查询需要0.2到0.5秒才能完成，其中包含所有数据。

请注意，我也尝试过只提供PartitionKey，但这并没有什么区别。我曾假设点查询会执行得更好。

从这个bug的演示中，我只能推测它是由于数据在第一次请求时是“冷”的，然后在连续请求时从“热”缓存中拉出来的。

如果是这种情况，如何更改过滤器字符串以提高性能？或者，如何更改表存储查询的超时时间，使其有更多时间完成查询？可以增加我的表存储的伸缩性吗？