使用IS_DEFINED的DocumentDB Extreme Query Cost

Question

我必须扩展查询以支持向后兼容旧版文档中可能不存在的属性，为此，我已使用IS_DEFINED方法检查布尔值字段存在于对象上。

我刚刚注意到，通过使用它，RU成本上升了15000％

  

SELECT T.id FROM Panels T WHERE T.customerId = @CustomerId

费用：~3 RU

  

SELECT T.id FROM Panels T WHERE T.customerId = @CustomerId AND（T.archived = false）

费用：~4 RU

  

SELECT T.id FROM Panels T WHERE T.customerId = @CustomerId AND（NOT IS_DEFINED（T.archived）OR T.archived = false）

费用：~450卢比

对于布尔字段来说，这是一个相当大的差异，并且真正打击了我们的吞吐量。

更新：在此处找到相关问题 - DocumentDB Query Requires Unexpected High RUs

看起来不是一个问题，所以需要某种逻辑，如：

  

SELECT T.id FROM Panels T WHERE T.customerId = @CustomerId AND IIF（IS_DEFINED（T.archived），T.archived，false）= false

但我想这仍然会涉及扫描？

更新2：

尝试在没有NOT的情况下运行操作，它在~750时进入，但它的结果集为1500个id字段。

Answer 1

T.customerId = @CustomerId上的过滤器将允许查询使用customerId上的索引，但不能使用archived上的索引。使用NOT的查询过滤器不使用DocumentDB中的索引（就像在任何数据库中一样）。扫描将导致消耗更多的RU。

也就是说，特定查询可能有不同的执行计划。由于DocumentDB是托管服务，因此您可以让DocumentDB团队通过提交Azure支持服务单或发送电子邮件至askdocdb@microsoft.com来调试任何性能问题。