DocumentDB：內置字符串函數的性能影響（如UPPER）

在我們的.NET應用程序中，我們使用DocumentDB SDK來查詢Azure DocumentDB。當我們意識到查詢中的內置字符串函數似乎對性能有很大影響時，我們試圖找出性能問題的原因。DocumentDB：內置字符串函數的性能影響（如UPPER）

我要粘貼一些統計數據，我從我們的應用程序了，但我已經能夠複製與操場這邊的情況： https://www.documentdb.com/sql/demo（點擊沙盒標籤上）

用下面的查詢：

SELECT * 
FROM food 
WHERE food.description="Babyfood, dessert, fruit pudding, orange, strained"

我得到：

並與UPPER字符串函數：

SELECT * 
FROM food 
WHERE UPPER(food.description)=UPPER("Babyfood, dessert, fruit pudding, orange, strained")

我得到：

的絕對數字並不真正的問題在這裏，在我們的應用上的電子郵件場施加UPPER，我們看到一個很大的區別。操作需要1s，沒有UPPER vs 20s！

來源

2016-11-09 phil_lgr

除少數例外情況外，每次使用字段值函數時，都無法使用索引，因此查詢變爲全表掃描。解決這個問題的最佳方法是將值存儲在已經UPPER的另一個字段中，並對其進行查詢。或者，如果您可以將更高選擇性的子句與UPPER（）子句組合在一起，您將獲得更好的性能。

來源

2016-11-09 23:02:53

令人驚訝的是，文檔沒有提到，他們列出了在查詢中使用這些函數的示例... https://azure.microsoft.com/en-us/documentation/articles/documentdb-sql-query/# _built-in-functions在我將您的答案標記爲已接受之前，您是否有任何有關該行爲的來源/鏈接？ –

DocumentDB團隊成員在這裏。如果查詢使用等號（=「[email protected]」）或範圍查詢（> =，<=, >，<），則查詢引擎可以使用索引，因爲數據按索引順序存儲在索引中，與查詢中請求的相同。 STARTSWITH和BETWEEN是相同的，所以它們也以相同的方式工作。幾乎所有數據庫都是如此，而不僅僅是DocumentDB。通過UPPER執行額外轉換的查詢或檢查CONTAINS等需要掃描所有條目，並且不能使用索引。 Larry建議的解決方法是處理此問題的最佳方法。 –

是的，這是所有數據庫的問題。字段上的函數產生表掃描。 –

DocumentDB：內置字符串函數的性能影響（如UPPER）

回答

相關問題