我对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的介绍中我只能假设它是由数据在第一次请求时“冷”引起的，然后在连续请求时从“热”缓存中拉出来。
如果是这种情况，我该如何更改过滤字符串以提高性能？或者，如何更改表存储查询的超时以使其有更多时间完成？是否可以增加表存储的缩放比例？
答案 0 :(得分：2)
请不要使用与＆＃39;或＆＃39;连接的点查询字符串，因为Azure存储表不能将其视为多点查询。相反，Azure Table会将其视为全表扫描，这在性能上非常糟糕。您应该分别执行25个点查询以提高性能。