DocumentDB:内置字符串函数(如UPPER)对性能的影响

phi*_*lgr 4 azure-cosmosdb

在我们的.NET应用程序中,我们使用DocumentDB SDK来查询Azure DocumentDB.当我们意识到查询中的内置字符串函数似乎对性能有很大影响时,我们试图找出性能问题的原因.

我打算粘贴我从应用程序中获得的一些统计数据,但我已经能够在操场上复制这种情况:https: //www.documentdb.com/sql/demo(点击沙箱选项卡)

使用以下查询:

SELECT *
FROM food 
WHERE food.description="Babyfood, dessert, fruit pudding, orange, strained"
Run Code Online (Sandbox Code Playgroud)

我明白了:

查询没有UPPER功能

并具有UPPER字符串功能:

SELECT *
FROM food 
WHERE UPPER(food.description)=UPPER("Babyfood, dessert, fruit pudding, orange, strained")
Run Code Online (Sandbox Code Playgroud)

我明白了:

使用UPPER字符串函数查询

绝对数字在这里并不重要,在我们的应用程序中,我们应用于UPPER电子邮件领域,我们看到了很大的不同.操作需要1秒,没有UPPERvs 20s!

Lar*_*one 7

除了少数例外,每当您在字段值上使用函数时,它都无法使用索引,因此查询将成为全表扫描.解决此问题的最佳方法是将值存储在已经UPPER的另一个字段中并对其进行查询.或者,如果您可以将更高选择性的子句与UPPER()子句结合使用,您将获得更好的性能.

  • DocumentDB团队成员在这里.如果您的查询使用相等(="a@b.com")或范围查询(> =,<=,>,<),则查询引擎可以使用索引,因为数据按前缀顺序存储在索引,与查询中请求的相同.STARTSWITH和BETWEEN是等价的,所以它们也以同样的方式工作.这种行为几乎适用于所有数据库,而不仅仅是DocumentDB.通过UPPER执行其他转换或检查CONTAINS等的查询需要扫描所有条目,并且不能使用索引.Larry建议的解决方法是处理此问题的最佳方法. (6认同)