6

这个页面（https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities）说：

请注意，在 $filter 字符串中最多允许进行 15 个离散比较。

然而，在我的实验中，我已经达到了这个极限并且没有任何副作用。例如，这是来自 Azure 存储资源管理器：

storageacct/table 的统计信息（“PartitionKey eq '1' or PartitionKey eq '2' or PartitionKey eq '3' or PartitionKey eq '4' or PartitionKey eq '5' or PartitionKey eq '6' or PartitionKey eq '7' or PartitionKey eq '8' 或 PartitionKey eq '9' 或 PartitionKey eq '10' 或 PartitionKey eq '11' 或 PartitionKey eq '12' 或 PartitionKey eq '13' 或 PartitionKey eq '14' 或 PartitionKey eq '15' 或 PartitionKey eq ' 16' 或 PartitionKey eq '17' 或 PartitionKey eq '18' 或 PartitionKey eq '19' 或 PartitionKey eq '20' 或 PartitionKey eq '21' 或 PartitionKey eq '22' 或 PartitionKey eq '23' 或 PartitionKey eq '24'或 PartitionKey eq '25' 或 PartitionKey eq '26'或 PartitionKey eq '27' 或 PartitionKey eq '28' 或 PartitionKey eq '29' 或 PartitionKey eq '30' 或 PartitionKey eq '31' 或 PartitionKey eq '32' 或 PartitionKey eq '33' 或 PartitionKey eq '34' 或 PartitionKey eq '35' 或 PartitionKey eq '36' 或 PartitionKey eq '37' 或 PartitionKey eq '38' 或 PartitionKey eq '39' 或 PartitionKey eq '40' 或 PartitionKey eq '41'"): 0 个实体或 PartitionKey eq '38' 或 PartitionKey eq '39' 或 PartitionKey eq '40' 或 PartitionKey eq '41'"): 0 个实体或 PartitionKey eq '38' 或 PartitionKey eq '39' 或 PartitionKey eq '40' 或 PartitionKey eq '41'"): 0 个实体

鉴于 15 个比较限制，我希望这个 $filter 会导致请求失败。

在我需要以某种方式解释“15 个离散比较”的情况下，我尝试了这个查询与各种和/或组合。它总是成功的。

上一代 Azure 表 API 的限制是否不再存在？

$filter 还有其他限制吗？比如最大字符串长度？

谢谢

** 编辑 **

我一直在对此进行更多尝试。假设Development Storage Emulator和真实的服务一样，一个查询中可以使用的比较运算符的数量并不是一个固定的数量。以下是一些实验结果，它们给出了成功的结果，其中当递增 1 时会导致错误：

(PK==V) and ((RK==V) or (RK==V) ... 97x) // 98 次比较，97 次非 PK 比较
（PK==V 和 RK==V）或（PK ==V and RK==V) ... 97x // 194 次比较，97 次非 PK 比较
(RK==V) 或 (RK==V) ... 98x // 98 次比较，98 次非 PK 比较
(PK==V) 或 (PK==V) ... 98x // 98 次比较，0 次​​非 PK 比较
(PK==V and RK==V and Prop=V) or (PK==V and RK ==V and Prop=V) ... 93x // 279 次比较，186 次非 PK 比较

我不确定从中得出什么结论。我可以安全地执行 (PK==V and RK==V) or'd 97 次，但我可以执行 (RK==V) or'd 98 次。我已经用相同的值和不同的值以及其他比较运算符进行了测试，而不仅仅是等于。

有了这些结果，我们怎么能预见到服务器会根据查询字符串返回错误呢？

数字 15 在哪里发挥作用？

** 编辑 **

我刚刚在实时存储帐户上尝试了所有测试，发现没有最大值。事实上，我能够继续成功添加运算符，直到它开始返回：

远程服务器返回错误：(414) Request-URI Too Long。

因此，我从存储模拟器获得的所有这些随机结果显然不适用于实时服务。而且15个比较限制根本不存在？（推测）

经过反复试验，当完整 URI 大约有 32768 (32KB) 个字符长时，我似乎开始收到 414 错误。这是一个完全编码的 URL，包括所有其他参数、方案、主机名等。我认为没有一种可靠的方法来预先计算 ExecuteQuery 生成的确切 URI 长度，所以我想可以只拆分请求开始在大约 32500 个字符的 $filter 字符串之后？然后不要指望它可以与存储模拟器一起使用......

4

3 回答 3

7

我还使用 REST API 和客户端库对其进行了测试。我还发现不存在 15 个离散比较限制。我可以添加很多比较，直到达到 URL 长度限制。这是我测试的。

  1. Table REST API，1000+ PK 比较。
  2. 表 REST API，1000 多个不同列的比较。
  3. 表客户端库，1000+ PK 比较。
  4. 表客户端库，1000 多个不同列的比较。

在 Azure 表客户端库文档中，我没有找到 15 个离散比较的限制。限制可能已过时。 Table​Query.​Filter​String 属性

您可以对以下文档发表评论，以获得文档所有者的官方回复。

查询表和实体

于 2017-05-16T02:17:49.490 回答
5

我只是想回应其他人的观察。

似乎没有 15 个比较限制。

在表存储上构建高性能应用程序需要尽可能少地往返服务，这意味着在单个请求中为服务器发送尽可能多的工作。

遗憾的是，真正的限制并未在任何地方发布，而且我发现的一个限制（15 次比较）并不是真正的限制。

在我的测试中，我观察到：

  • 32,684 url​​ 长度产生 200 好的
  • 32,685 url 长度产生 414 URL 太长
  • 为已知键发送的每个行键比较都会得到尊重，并在 HTTP 响应中产生结果。没有观察到限制。
于 2019-03-04T16:32:24.407 回答
1

我联系了相应的 Azure 产品组，并确认 Azure 代码中不存在 15 项限制。将有一个文档更新来反映这一点。对不起这里的混乱！

于 2020-09-09T17:46:00.387 回答