Azure Table 查询中的最大 $filter 比较
Max $filter comparisons in an Azure Table Query
此页面 (https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities) 说：
Note that no more than 15 discrete comparisons are permitted within a $filter string.
然而，在我的实验中，我达到了那个极限并且没有任何副作用。例如，这来自 Azure 存储资源管理器：
Statistics for 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' or PartitionKey eq '9' or PartitionKey eq '10' or PartitionKey eq '11' or PartitionKey eq '12' or PartitionKey eq '13' or PartitionKey eq '14' or PartitionKey eq '15' or PartitionKey eq '16' or PartitionKey eq '17' or PartitionKey eq '18' or PartitionKey eq '19' or PartitionKey eq '20' or PartitionKey eq '21' or PartitionKey eq '22' or PartitionKey eq '23' or PartitionKey eq '24' or PartitionKey eq '25' or PartitionKey eq '26' or PartitionKey eq '27' or PartitionKey eq '28' or PartitionKey eq '29' or PartitionKey eq '30' or PartitionKey eq '31' or PartitionKey eq '32' or PartitionKey eq '33' or PartitionKey eq '34' or PartitionKey eq '35' or PartitionKey eq '36' or PartitionKey eq '37' or PartitionKey eq '38' or PartitionKey eq '39' or PartitionKey eq '40' or PartitionKey eq '41'"): 0 entities
考虑到 15 个比较限制，我预计此 $filter 会导致请求失败。
在我需要以某种方式解释“15 次离散比较”的情况下，我使用各种 and/or 组合尝试了此查询。它总是成功。
上一代 Azure Table API 的这种限制是否不再存在？
$filter 还有其他限制吗？比如最大字符串长度？
谢谢
** 编辑 **
我一直在对此进行更多试验。假设Development Storage Emulator和真实的服务是一样的，一个查询中可以使用的比较运算符的个数不是固定的。以下是一些给出成功结果的实验结果，其中递增 1 会导致错误：
(PK==V) and ((RK==V) or (RK==V) ... 97x) // 98 次比较，97 次非 PK 比较
(PK==V and RK==V) or (PK==V and RK==V) ... 97x // 194 次比较，97 次非 PK 比较
(RK==V) or (RK==V) ... 98x // 98 次比较，98 次非 PK 比较
(PK==V) or (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 次。我已经用相同的值和不同的值以及其他比较运算符（而不仅仅是等于）对此进行了测试。
根据这些结果，如何可以预测地知道服务器会 return 基于查询字符串的错误？
数字 15 在哪里发挥作用？
** 编辑 **
我刚刚在实时存储帐户上尝试了所有测试，发现没有最大值。事实上，我能够继续成功添加运算符，直到它开始 returning:
远程服务器 return 出现错误：(414) 请求 URI 太长。
因此，我从存储模拟器获得的所有这些随机结果显然不适用于实时服务。而且 15 比较限制根本不存在了？ （猜想）
从反复试验来看，当完整 URI 的长度约为 32768 (32KB) 个字符时，我似乎开始收到 414 错误。这是一个完全编码的 URL，包括所有其他参数、方案、主机名等。我认为没有可靠的方法来预先计算由 ExecuteQuery 生成的确切 URI 长度，所以我想可以在大约 32500 个字符 $filter 字符串之后拆分请求？然后不要期望它可以与存储模拟器一起使用...
我还使用 REST API 和客户端库对其进行了测试。我还发现不存在 15 次离散比较限制。我可以添加很多比较，直到达到 URL 长度限制。这是我测试的内容。
- Table REST API, 1000+PK对比
- Table REST API，与不同列的 1000 多次比较。
- Table客户端库，1000+PK对比
- Table 客户端库，1000 多次与不同列的比较。
在 Azure Table 客户端库文档中，我没有找到 15 个离散比较限制。该限制可能已过时。
TableQuery.FilterString Property
您可以post对以下文档发表评论，以获得文档所有者的正式回复。
我只是想回应其他人的观察。
似乎没有 15 个比较限制。
在 table 存储上构建高性能应用程序需要尽可能少地往返服务，这意味着在单个请求中发送尽可能多的工作让服务器完成。
遗憾的是，真正的限制并未在任何地方公布，而且我发现的一个限制（15 次比较）并不是真正的限制。
在我的测试中我观察到：
- 32,684 url 长度产生 200 ok
- 32,685 url 长度产生 414 URL 太长
- 为已知键发送的每个行键比较都得到认可，并在 HTTP 响应中产生了结果。没有观察到限制。
我联系了相应的 Azure 产品组并确认 Azure 代码中不存在 15 项限制。将有一个文档更新来反映这一点。很抱歉这里的混乱！
此页面 (https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities) 说：
Note that no more than 15 discrete comparisons are permitted within a $filter string.
然而，在我的实验中，我达到了那个极限并且没有任何副作用。例如，这来自 Azure 存储资源管理器：
Statistics for 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' or PartitionKey eq '9' or PartitionKey eq '10' or PartitionKey eq '11' or PartitionKey eq '12' or PartitionKey eq '13' or PartitionKey eq '14' or PartitionKey eq '15' or PartitionKey eq '16' or PartitionKey eq '17' or PartitionKey eq '18' or PartitionKey eq '19' or PartitionKey eq '20' or PartitionKey eq '21' or PartitionKey eq '22' or PartitionKey eq '23' or PartitionKey eq '24' or PartitionKey eq '25' or PartitionKey eq '26' or PartitionKey eq '27' or PartitionKey eq '28' or PartitionKey eq '29' or PartitionKey eq '30' or PartitionKey eq '31' or PartitionKey eq '32' or PartitionKey eq '33' or PartitionKey eq '34' or PartitionKey eq '35' or PartitionKey eq '36' or PartitionKey eq '37' or PartitionKey eq '38' or PartitionKey eq '39' or PartitionKey eq '40' or PartitionKey eq '41'"): 0 entities
考虑到 15 个比较限制，我预计此 $filter 会导致请求失败。
在我需要以某种方式解释“15 次离散比较”的情况下，我使用各种 and/or 组合尝试了此查询。它总是成功。
上一代 Azure Table API 的这种限制是否不再存在？
$filter 还有其他限制吗？比如最大字符串长度？
谢谢
** 编辑 **
我一直在对此进行更多试验。假设Development Storage Emulator和真实的服务是一样的，一个查询中可以使用的比较运算符的个数不是固定的。以下是一些给出成功结果的实验结果，其中递增 1 会导致错误：
(PK==V) and ((RK==V) or (RK==V) ... 97x) // 98 次比较，97 次非 PK 比较
(PK==V and RK==V) or (PK==V and RK==V) ... 97x // 194 次比较，97 次非 PK 比较
(RK==V) or (RK==V) ... 98x // 98 次比较，98 次非 PK 比较
(PK==V) or (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 次。我已经用相同的值和不同的值以及其他比较运算符（而不仅仅是等于）对此进行了测试。
根据这些结果，如何可以预测地知道服务器会 return 基于查询字符串的错误？
数字 15 在哪里发挥作用？
** 编辑 **
我刚刚在实时存储帐户上尝试了所有测试，发现没有最大值。事实上，我能够继续成功添加运算符，直到它开始 returning:
远程服务器 return 出现错误：(414) 请求 URI 太长。
因此，我从存储模拟器获得的所有这些随机结果显然不适用于实时服务。而且 15 比较限制根本不存在了？ （猜想）
从反复试验来看，当完整 URI 的长度约为 32768 (32KB) 个字符时，我似乎开始收到 414 错误。这是一个完全编码的 URL，包括所有其他参数、方案、主机名等。我认为没有可靠的方法来预先计算由 ExecuteQuery 生成的确切 URI 长度，所以我想可以在大约 32500 个字符 $filter 字符串之后拆分请求？然后不要期望它可以与存储模拟器一起使用...
我还使用 REST API 和客户端库对其进行了测试。我还发现不存在 15 次离散比较限制。我可以添加很多比较，直到达到 URL 长度限制。这是我测试的内容。
- Table REST API, 1000+PK对比
- Table REST API，与不同列的 1000 多次比较。
- Table客户端库，1000+PK对比
- Table 客户端库，1000 多次与不同列的比较。
在 Azure Table 客户端库文档中，我没有找到 15 个离散比较限制。该限制可能已过时。 TableQuery.FilterString Property
您可以post对以下文档发表评论，以获得文档所有者的正式回复。
我只是想回应其他人的观察。
似乎没有 15 个比较限制。
在 table 存储上构建高性能应用程序需要尽可能少地往返服务，这意味着在单个请求中发送尽可能多的工作让服务器完成。
遗憾的是，真正的限制并未在任何地方公布，而且我发现的一个限制（15 次比较）并不是真正的限制。
在我的测试中我观察到：
- 32,684 url 长度产生 200 ok
- 32,685 url 长度产生 414 URL 太长
- 为已知键发送的每个行键比较都得到认可，并在 HTTP 响应中产生了结果。没有观察到限制。
我联系了相应的 Azure 产品组并确认 Azure 代码中不存在 15 项限制。将有一个文档更新来反映这一点。很抱歉这里的混乱！