Rozwiązywanie problemów z zapytaniami podczas korzystania z usługi Azure Cosmos DB
DOTYCZY: 
NoSQL
W tym artykule przedstawiono ogólne zalecane podejście do rozwiązywania problemów z zapytaniami w usłudze Azure Cosmos DB. Chociaż nie należy brać pod uwagę kroków opisanych w tym artykule pełnej ochrony przed potencjalnymi problemami z zapytaniami, uwzględniliśmy tutaj najbardziej typowe porady dotyczące wydajności. W tym artykule należy użyć jako miejsca początkowego do rozwiązywania problemów z powolnymi lub kosztownymi zapytaniami w usłudze Azure Cosmos DB for NoSQL. Można również używać dzienników diagnostycznych do identyfikowania zapytań, które są powolne lub zużywają znaczną ilość przepływności. Jeśli używasz interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB, użyj interfejsu API usługi Azure Cosmos DB dla bazy danych MongoDB — przewodnik rozwiązywania problemów z zapytaniami
Optymalizacje zapytań w usłudze Azure Cosmos DB są szeroko kategoryzowane w następujący sposób:
- Optymalizacje, które zmniejszają opłatę za jednostkę żądania (RU) zapytania
- Optymalizacje, które zmniejszają opóźnienie
Jeśli zmniejszysz opłatę za jednostki RU zapytania, zwykle również zmniejszysz opóźnienie.
Typowe problemy z zestawem SDK
Przed przeczytaniem tego przewodnika warto rozważyć typowe problemy z zestawem SDK, które nie są związane z aparatem zapytań.
- Postępuj zgodnie z poniższymi wskazówkami dotyczącymi wydajności zestawu SDK, aby uzyskać zapytanie.
- Czasami w zapytaniach mogą być puste strony, nawet jeśli na kolejnej stronie znajdują się wyniki. Przyczyny tego mogą być następujące:
- Zestaw SDK może wykonywać wiele wywołań sieciowych.
- Pobieranie dokumentów przez zapytanie może zająć dużo czasu.
- Wszystkie zapytania mają token kontynuacji, który umożliwia kontynuowanie zapytania. Pamiętaj, aby całkowicie opróżnić zapytanie. Dowiedz się więcej o obsłudze wielu stron wyników
Pobieranie metryk zapytania
Podczas optymalizowania zapytania w usłudze Azure Cosmos DB pierwszym krokiem jest zawsze uzyskanie metryk zapytania dla zapytania. Te metryki są również dostępne w witrynie Azure Portal. Po uruchomieniu zapytania w Eksploratorze danych metryki zapytania są widoczne obok karty Wyniki :
Po pobraniu metryk zapytania porównaj liczbę pobranych dokumentów z liczbą dokumentów wyjściowych dla zapytania. Użyj tego porównania, aby zidentyfikować odpowiednie sekcje do przejrzenia w tym artykule.
Liczba pobranych dokumentów to liczba dokumentów wymaganych do załadowania aparatu zapytań. Liczba dokumentów wyjściowych to liczba dokumentów, które były potrzebne do wykonania wyników zapytania. Jeśli liczba pobranych dokumentów jest wyższa niż liczba dokumentów wyjściowych, co najmniej jedna część zapytania, która nie może użyć indeksu i musi wykonać skanowanie.
Zapoznaj się z poniższymi sekcjami, aby zrozumieć odpowiednie optymalizacje zapytań dla danego scenariusza.
Opłata za jednostkę ŻĄDANIA zapytania jest zbyt wysoka
Liczba pobranych dokumentów jest wyższa niż liczba dokumentów wyjściowych
Liczba pobranych dokumentów jest w przybliżeniu równa liczbie dokumentów wyjściowych
Zoptymalizuj zapytania, które mają filtry dla wielu właściwości.
Zoptymalizuj zapytania, które mają zarówno filtr, jak i klauzulę ORDER BY.
Opłaty za jednostki RU zapytania są akceptowalne, ale opóźnienie jest nadal zbyt wysokie
Zapytania, w których liczba pobranych dokumentów przekracza liczbę dokumentów wyjściowych
Liczba pobranych dokumentów to liczba dokumentów wymaganych do załadowania aparatu zapytań. Liczba dokumentów wyjściowych to liczba dokumentów zwracanych przez zapytanie. Jeśli liczba pobranych dokumentów jest wyższa niż liczba dokumentów wyjściowych, co najmniej jedna część zapytania, która nie może użyć indeksu i musi wykonać skanowanie.
Oto przykład zapytania skanowania, które nie zostało całkowicie obsłużone przez indeks:
Zapytanie:
SELECT VALUE c.description
FROM c
WHERE UPPER(c.description) = "BABYFOOD, DESSERT, FRUIT DESSERT, WITHOUT ASCORBIC ACID, JUNIOR"
Metryki zapytań:
Retrieved Document Count : 60,951
Retrieved Document Size : 399,998,938 bytes
Output Document Count : 7
Output Document Size : 510 bytes
Index Utilization : 0.00 %
Total Query Execution Time : 4,500.34 milliseconds
Query Preparation Times
Query Compilation Time : 0.09 milliseconds
Logical Plan Build Time : 0.05 milliseconds
Physical Plan Build Time : 0.04 milliseconds
Query Optimization Time : 0.01 milliseconds
Index Lookup Time : 0.01 milliseconds
Document Load Time : 4,177.66 milliseconds
Runtime Execution Times
Query Engine Times : 322.16 milliseconds
System Function Execution Time : 85.74 milliseconds
User-defined Function Execution Time : 0.00 milliseconds
Document Write Time : 0.01 milliseconds
Client Side Metrics
Retry Count : 0
Request Charge : 4,059.95 RUs
Liczba pobranych dokumentów (60 951) jest większa niż liczba dokumentów wyjściowych (7), co oznacza, że to zapytanie spowodowało skanowanie dokumentu. W takim przypadku funkcja systemowa UPPER() nie używa indeksu.
Uwzględnianie niezbędnych ścieżek w zasadach indeksowania
Zasady indeksowania powinny obejmować wszystkie właściwości zawarte w WHERE klauzulach, ORDER BY klauzulach, JOINi większości funkcji systemowych. Żądane ścieżki określone w zasadach indeksowania powinny być zgodne z właściwościami w dokumentach JSON.
Uwaga
Właściwości zasad indeksowania usługi Azure Cosmos DB są wrażliwe na wielkość liter
Oryginalne
Zapytanie:
SELECT *
FROM c
WHERE c.description = "Malabar spinach, cooked"
Zasady indeksowania:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/description/*"
}
]
}
Opłata za jednostki RU: 409,51 RU
Optymalizacja
Zaktualizowane zasady indeksowania:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": []
}
Opłata za jednostki RU: 2,98 RU
Właściwości można dodawać do zasad indeksowania w dowolnym momencie bez wpływu na dostępność zapisu ani odczytu. Możesz śledzić postęp transformacji indeksu.
Informacje o funkcjach systemowych korzystających z indeksu
Większość funkcji systemowych używa indeksów. Oto lista typowych funkcji ciągów korzystających z indeksów:
- StartsWith
- Contains
- RegexMatch
- Left
- Podciąg — ale tylko wtedy, gdy pierwsza num_expr wynosi 0
Poniżej przedstawiono niektóre typowe funkcje systemowe, które nie korzystają z indeksu i muszą załadować każdy dokument, gdy jest używany w klauzuli WHERE :
| Funkcja systemowa | Pomysły na optymalizację |
|---|---|
| Górny/dolny | Zamiast używać funkcji systemowej do normalizacji danych dla porównań, normalizuj wielkość liter po wstawieniu. Zapytanie, takie jak SELECT * FROM c WHERE UPPER(c.name) = 'BOB' , staje SELECT * FROM c WHERE c.name = 'BOB'się . |
| GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks | Oblicz bieżący czas przed wykonaniem zapytania i użyj tej wartości ciągu w klauzuli WHERE . |
| Funkcje matematyczne (nie agregujące) | Jeśli musisz obliczyć wartość często w zapytaniu, rozważ zapisanie wartości jako właściwości w dokumencie JSON. |
Te funkcje systemowe mogą używać indeksów, z wyjątkiem sytuacji, gdy są używane w zapytaniach z agregacjami:
| Funkcja systemowa | Pomysły na optymalizację |
|---|---|
| Funkcje systemu przestrzennego | Przechowywanie wyniku zapytania w widoku zmaterializowanym w czasie rzeczywistym |
W przypadku użycia w klauzuli SELECT nieefektywne funkcje systemowe nie będą wpływać na sposób używania indeksów przez zapytania.
Ulepszanie wykonywania funkcji systemowej ciągów
W przypadku niektórych funkcji systemowych korzystających z indeksów można ulepszyć wykonywanie zapytań, dodając klauzulę ORDER BY do zapytania.
Dokładniej rzecz biorąc, każda funkcja systemowa, której opłata za jednostkę RU zwiększa się w miarę wzrostu kardynalności właściwości, może korzystać z posiadania ORDER BY w zapytaniu. Te zapytania wykonują skanowanie indeksu, dzięki czemu posortowane wyniki zapytania mogą zwiększyć wydajność zapytania.
Ta optymalizacja może poprawić wykonywanie następujących funkcji systemowych:
- StartsWith (gdzie bez uwzględniania wielkości liter = true)
- StringEquals (gdzie bez uwzględniania wielkości liter = true)
- Contains
- RegexMatch
- EndsWith
Rozważmy na przykład poniższe zapytanie za pomocą polecenia CONTAINS. CONTAINS Będzie używać indeksów, ale czasami nawet po dodaniu odpowiedniego indeksu podczas uruchamiania poniższego zapytania nadal można obserwować wysokie opłaty za jednostki RU.
Oryginalne zapytanie:
SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
Możesz ulepszyć wykonywanie zapytań, dodając :ORDER BY
SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
ORDER BY c.town
Ta sama optymalizacja może pomóc w zapytaniach z innymi filtrami. W takim przypadku najlepiej również dodać właściwości z filtrami równości do klauzuli ORDER BY .
Oryginalne zapytanie:
SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
Wykonywanie zapytań można poprawić, dodając ORDER BY indeks złożony (c.name, c.town):
SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
ORDER BY c.name, c.town
Informacje o tym, które zapytania zagregowane używają indeksu
W większości przypadków zagregowane funkcje systemowe w usłudze Azure Cosmos DB używają indeksu. Jednak w zależności od filtrów lub innych klauzul w zagregowanym zapytaniu aparat zapytań może być wymagany do załadowania dużej liczby dokumentów. Zazwyczaj aparat zapytań stosuje najpierw filtry równości i zakresu. Po zastosowaniu tych filtrów aparat zapytań może oceniać inne filtry i uciekać się do ładowania pozostałych dokumentów w celu obliczenia agregacji, jeśli jest to konieczne.
Na przykład, biorąc pod uwagę te dwa przykładowe zapytania, zapytanie z równością i CONTAINS filtrem funkcji systemu jest ogólnie bardziej wydajne niż zapytanie z tylko filtrem CONTAINS funkcji systemu. Wynika to z faktu, że filtr równości jest stosowany jako pierwszy i używa indeksu przed załadowaniem dokumentów do droższego CONTAINS filtru.
Zapytanie tylko z filtrem CONTAINS — wyższe opłaty za jednostki RU:
SELECT COUNT(1)
FROM c
WHERE CONTAINS(c.description, "spinach")
Zapytanie z filtrem równości i CONTAINS filtrem — niższe opłaty za jednostki RU:
SELECT AVG(c._ts)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats" AND CONTAINS(c.description, "spinach")
Poniżej przedstawiono więcej przykładów zagregowanych zapytań, które nie będą w pełni korzystać z indeksu:
Zapytania z funkcjami systemowymi, które nie korzystają z indeksu
Aby sprawdzić, czy używa indeksu, należy odwołać się do strony odpowiedniej funkcji systemowej.
SELECT MAX(c._ts)
FROM c
WHERE CONTAINS(c.description, "spinach")
Agregowanie zapytań przy użyciu funkcji zdefiniowanych przez użytkownika (UDF)
SELECT AVG(c._ts)
FROM c
WHERE udf.MyUDF("Sausages and Luncheon Meats")
Zapytania z grupą WEDŁUG
Opłaty za jednostki RU zapytań ze wzrostem GROUP BY w miarę zwiększania kardynalności właściwości w klauzuli GROUP BY . Na przykład w poniższym zapytaniu opłaty za jednostkę RU zapytania rosną wraz ze wzrostem liczby unikatowych opisów.
Opłaty za jednostkę RU funkcji agregującej z klauzulą GROUP BY są wyższe niż opłaty za jednostkę RU samej funkcji agregującej. W tym przykładzie aparat zapytań musi załadować każdy dokument zgodny z filtrem c.foodGroup = "Sausages and Luncheon Meats" , aby opłata za jednostkę ŻĄDANIA miała być wysoka.
SELECT COUNT(1)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats"
GROUP BY c.description
Jeśli planujesz często uruchamiać te same zagregowane zapytania, tworzenie zmaterializowanego widoku w czasie rzeczywistym przy użyciu źródła zmian usługi Azure Cosmos DB może być bardziej wydajne niż uruchamianie poszczególnych zapytań.
Optymalizowanie zapytań, które mają zarówno filtr, jak i klauzulę ORDER BY
Chociaż zapytania, które mają filtr i klauzulę ORDER BY , zwykle używają indeksu zakresu, są bardziej wydajne, jeśli można je obsłużyć z indeksu złożonego. Oprócz modyfikowania zasad indeksowania należy dodać wszystkie właściwości w indeksie złożonym do klauzuli ORDER BY . Ta zmiana w zapytaniu gwarantuje, że używa indeksu złożonego.
Oryginalne
Zapytanie:
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c._ts ASC
Zasady indeksowania:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[]
}
Opłata za jednostki RU: 44,28 jednostek RU
Optymalizacja
Zaktualizowane zapytanie (zawiera obie właściwości klauzuli ORDER BY ):
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c.foodGroup, c._ts ASC
Zaktualizowane zasady indeksowania:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[],
"compositeIndexes":[
[
{
"path":"/foodGroup",
"order":"ascending"
},
{
"path":"/_ts",
"order":"ascending"
}
]
]
}
Opłata za jednostki RU: 8,86 jednostek RU
Optymalizowanie wyrażeń JOIN przy użyciu podzapytania
Podzapytania wielu wartości mogą optymalizować JOIN wyrażenia, wypychając predykaty po każdym wyrażeniu select-many, a nie po wszystkich sprzężeniach krzyżowych w klauzuli WHERE .
Rozważ następujące zapytanie:
SELECT Count(1) AS Count
FROM c
JOIN t IN c.tags
JOIN n IN c.nutrients
JOIN s IN c.servings
WHERE t.name = 'infant formula' AND (n.nutritionValue > 0
AND n.nutritionValue < 10) AND s.amount > 1
Opłata za jednostkę RU: 167,62 jednostki RU
W przypadku tego zapytania indeks pasuje do każdego dokumentu, który ma tag o nazwie infant formula, nutritionValue większej niż 0 i amount większej niż 1. Wyrażenie JOIN w tym miejscu wykonuje krzyżowy produkt wszystkich elementów tagów, składników odżywczych i obsługujących tablice dla każdego zgodnego dokumentu przed zastosowaniem filtru. Klauzula WHERE będzie następnie stosować predykat filtru dla każdej <c, t, n, s> krotki.
Jeśli na przykład pasujący dokument zawiera 10 elementów w każdej z trzech tablic, rozszerza się do 1 x 10 x 10 x 10 (czyli 10000) krotek. Użycie podzapytania może pomóc w odfiltrowyniu sprzężonych elementów tablicy przed dołączeniem do następnego wyrażenia.
To zapytanie jest równoważne poprzedniemu, ale używa podzapytania:
SELECT Count(1) AS Count
FROM c
JOIN (SELECT VALUE t FROM t IN c.tags WHERE t.name = 'infant formula')
JOIN (SELECT VALUE n FROM n IN c.nutrients WHERE n.nutritionValue > 0 AND n.nutritionValue < 10)
JOIN (SELECT VALUE s FROM s IN c.servings WHERE s.amount > 1)
Opłata za jednostki RU: 22,17 jednostek RU
Załóżmy, że tylko jeden element w tablicy tagów jest zgodny z filtrem i że istnieje pięć elementów dla składników odżywczych i tablic obsługujących. Wyrażenia JOIN rozszerzają się do 1 x 1 x 5 x 5 = 25 elementów, w przeciwieństwie do 1000 elementów w pierwszym zapytaniu.
Zapytania, w których liczba pobranych dokumentów jest równa liczbie dokumentów wyjściowych
Jeśli liczba pobranych dokumentów jest w przybliżeniu równa liczbie dokumentów wyjściowych, oznacza to, że aparat zapytań nie musiał skanować wielu niepotrzebnych dokumentów. W przypadku wielu zapytań, takich jak te, które używają słowa kluczowego TOP , liczba pobranych dokumentów może przekroczyć liczbę dokumentów wyjściowych o 1. Nie należy się tym martwić.
Minimalizowanie liczby zapytań między partycjami
Usługa Azure Cosmos DB używa partycjonowania do skalowania poszczególnych kontenerów w miarę zwiększania się zapotrzebowania na jednostkę żądania i magazyn danych. Każda partycja fizyczna ma oddzielny i niezależny indeks. Jeśli zapytanie ma filtr równości zgodny z kluczem partycji kontenera, musisz sprawdzić tylko indeks odpowiedniej partycji. Ta optymalizacja zmniejsza łączną liczbę jednostek RU, których wymaga zapytanie.
Jeśli masz dużą liczbę aprowizowanych jednostek RU (ponad 30 000) lub dużą ilość przechowywanych danych (więcej niż około 100 GB), prawdopodobnie masz wystarczająco duży kontener, aby zobaczyć znaczną redukcję opłat za jednostki RU zapytań.
Jeśli na przykład utworzysz kontener z kluczem partycji foodGroup, następujące zapytania muszą sprawdzić tylko jedną partycję fizyczną:
SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"
Zapytania, które mają IN filtr z kluczem partycji, sprawdzają tylko jedną lub więcej odpowiednich partycji fizycznych i nie będą "fan-out":
SELECT *
FROM c
WHERE c.foodGroup IN("Soups, Sauces, and Gravies", "Vegetables and Vegetable Products") and c.description = "Mushroom, oyster, raw"
Zapytania, które mają filtry zakresu dla klucza partycji lub które nie mają żadnych filtrów w kluczu partycji, będą musiały "fan-out" i sprawdzić indeks każdej partycji fizycznej pod kątem wyników:
SELECT *
FROM c
WHERE c.description = "Mushroom, oyster, raw"
SELECT *
FROM c
WHERE c.foodGroup > "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"
Optymalizowanie zapytań z filtrami dla wielu właściwości
Chociaż zapytania, które mają filtry dla wielu właściwości, zwykle używają indeksu zakresu, są bardziej wydajne, jeśli można je obsłużyć z indeksu złożonego. W przypadku małych ilości danych ta optymalizacja nie będzie miała znaczącego wpływu. Może być jednak przydatna w przypadku dużych ilości danych. Można zoptymalizować tylko jeden filtr, który nie jest filtrem równości, na indeks złożony. Jeśli zapytanie ma wiele filtrów innych niż filtr równości, wybierz jeden z nich, który będzie używać indeksu złożonego. Reszta nadal używa indeksów zakresu. Filtr bez równości musi być zdefiniowany jako ostatni w indeksie złożonym. Dowiedz się więcej o indeksach złożonych.
Oto kilka przykładów zapytań, które można zoptymalizować za pomocą indeksu złożonego:
SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts = 1575503264
SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts > 1575503264
Oto odpowiedni indeks złożony:
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[],
"compositeIndexes":[
[
{
"path":"/foodGroup",
"order":"ascending"
},
{
"path":"/_ts",
"order":"ascending"
}
]
]
}
Optymalizacje, które zmniejszają opóźnienie zapytań
W wielu przypadkach koszt w jednostkach RU może być akceptowalny, gdy opóźnienie zapytania jest nadal zbyt duże. W poniższych sekcjach przedstawiono omówienie wskazówek dotyczących zmniejszenia opóźnienia zapytań. Jeśli uruchamiasz to samo zapytanie wiele razy względem tego samego zestawu danych, zwykle koszt w jednostkach RU będzie taki sam. Jednak opóźnienie zapytań może się różnić między ich wykonaniami.
Poprawianie odległości
Zapytania uruchamiane z innego regionu niż konto usługi Azure Cosmos DB mają większe opóźnienie niż w przypadku uruchomienia ich w tym samym regionie. Jeśli na przykład uruchamiasz kod na komputerze stacjonarnym, możesz oczekiwać opóźnienia większego o co najmniej dziesiątki lub setki milisekund niż gdyby zapytanie pochodziło z maszyny wirtualnej w tym samym regionie świadczenia platformy Azure co usługa Azure Cosmos DB. Dane w usłudze Azure Cosmos DB można łatwo dystrybuować globalnie, aby zapewnić zbliżenie danych do aplikacji.
Zwiększanie aprowizowanej przepływności
W usłudze Azure Cosmos DB aprowizowana przepływność jest mierzona w jednostkach żądań (RU). Załóżmy, że masz zapytanie, które zużywa 5 jednostek RU przepływności. Jeśli na przykład aprowizujesz 1000 jednostek RU, możesz uruchomić to zapytanie 200 razy na sekundę. Jeśli podjęto próbę uruchomienia zapytania, gdy nie było wystarczającej przepływności, usługa Azure Cosmos DB zwróci błąd HTTP 429. Każdy z bieżących zestawów SDK interfejsu API dla noSQL automatycznie ponowi próbę tego zapytania po odczekaniu krótkiego czasu. Wykonywanie ograniczonych żądań trwa dłużej, więc zwiększenie aprowizowanej przepływności może skrócić opóźnienie zapytań. Łączna liczba żądań ograniczonych można obserwować w bloku Metryki w witrynie Azure Portal.
Zwiększ wartość MaxConcurrency
Zapytania równoległe działają równolegle, wykonując zapytania o wiele partycji. Jednak dane z pojedynczej kolekcji partycjonowanej są pobierane szeregowo w odniesieniu do zapytania. Dlatego jeśli ustawisz wartość MaxConcurrency na liczbę partycji, masz największe szanse na osiągnięcie najbardziej wydajnego zapytania, pod warunkiem, że wszystkie inne warunki systemowe pozostaną takie same. Jeśli nie znasz liczby partycji, możesz ustawić parametr MaxConcurrency (lub MaxDegreesOfParallelism w starszych wersjach zestawu SDK) na dużą liczbę. System wybiera minimalną (liczbę partycji, dane wejściowe podane przez użytkownika) jako maksymalny stopień równoległości.
Zwiększ wartość MaxBufferedItemCount
Zapytania są przeznaczone do wstępnego pobierania wyników, gdy bieżąca partia wyników jest przetwarzana przez klienta. Wstępne pobieranie pomaga poprawić ogólne opóźnienie zapytania. Ustawienie parametru MaxBufferedItemCount ogranicza liczbę wstępnie pobranych wyników. Jeśli ustawisz tę wartość na oczekiwaną liczbę zwróconych wyników (lub większą liczbę), zapytanie może uzyskać największą korzyść z pobierania wstępnego. Jeśli ustawisz tę wartość na -1, system automatycznie określi liczbę elementów do buforowania.
Następne kroki
Zapoznaj się z następującymi artykułami, aby uzyskać informacje na temat mierzenia jednostek RU na zapytanie, uzyskiwania statystyk wykonywania w celu dostosowania zapytań i nie tylko: