Analizowanie wykonywania zapytań za pomocą funkcji Query Explain

Na tej stronie opisujemy, jak pobierać informacje o wykonywaniu zapytań.

Korzystanie z funkcji Wyjaśnij zapytanie

Za pomocą funkcji Wyjaśnienie zapytania możesz sprawdzić, jak są wykonywane Twoje zapytania. Zawiera ona szczegółowe informacje, które możesz wykorzystać do optymalizacji zapytań.

Możesz użyć funkcji Wyjaśnij zapytanie w konsoli Google Cloud lub za pomocą polecenia explain.

Konsola

Wykonaj zapytanie w edytorze zapytań i otwórz kartę Wyjaśnienie:

  1. W konsoli Google Cloud otwórz stronę Bazy danych.

    Otwórz Bazy danych

  2. Z listy baz danych wybierz bazę danych Cloud Firestore. W konsoli Google Cloud otworzy się Eksplorator Firestore dla tej bazy danych.
  3. Wpisz zapytanie w edytorze zapytań i kliknij Uruchom.

  4. Kliknij kartę Wyjaśnienie, aby wyświetlić dane wyjściowe analizy zapytania.

    Karta Wyjaśnienie zapytania w konsoli
MongoDB API

Zapytanie Explain w interfejsie MongoDB API jest obsługiwane przez polecenie explain, którego możesz używać w narzędziach takich jak Mongo Shell i Compass.

Polecenie explain jest obsługiwane w przypadku poleceń aggregate, find, distinct i count, na przykład:

db.collection.explain('executionStats').find(...)

Możesz też użyć metody explain(), na przykład:

db.collection.find({QUERY}).explain('executionStats')
Ograniczenia
Pamiętaj o tych ograniczeniach i różnicach:

  • Funkcja Wyjaśnij zapytanie nie obsługuje poleceń, które zwracają kursor. Na przykład wywoływanie wyjaśnienia przez bezpośrednie wywołanie tego polecenia nie jest obsługiwane:

    db.collection.aggregate(..., explain: true)

  • Funkcja wyjaśniania zapytań jest obsługiwana tylko w przypadku poleceń find, aggregate, count, distinct, update, delete i findAndModify.

  • Funkcja Wyjaśnij zapytanie obsługuje tryby szczegółowości executionStats, allPlansExecution i queryPlanner.

    • queryPlanner: zwraca tylko plan wykonania, bez wykonywania zapytania.
    • executionStats i allPlansExecution: zwraca plan wykonania wraz ze statystykami rozliczeń, pamięci i wykonania.

    Jeśli nie określisz trybu szczegółowości, powłoka domyślnie użyje trybu queryPlanner. Aby zobaczyć pełne statystyki wykonania, musisz określić tryb szczegółowości executionStats lub allPlansExecution.

Analiza

Dane wyjściowe funkcji Query Explain zawierają 2 główne komponenty: statystyki podsumowujące i drzewo wykonania. Weźmy na przykład to zapytanie:

db.orders.aggregate(
 [
   { "$match": { "user_id": 1234 } },
   { "$sort": { "date_placed": 1 } }
 ]
)

Statystyki podsumowujące

U góry wyjaśnionych danych wyjściowych znajduje się podsumowanie statystyk wykonania. Korzystaj z tych statystyk, aby określić, czy zapytanie ma długi czas oczekiwania lub wysoki koszt. Zawiera też statystyki pamięci, które informują, jak blisko zapytanie jest limitów pamięci.

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

Drzewo wykonania

Drzewo wykonania opisuje wykonanie zapytania jako serię węzłów. Węzły dolne (węzły liści) pobierają dane z warstwy pamięci, które są przekazywane w górę drzewa, aby wygenerować odpowiedź na zapytanie.

Szczegółowe informacje o poszczególnych węzłach wykonawczych znajdziesz w informacjach o wykonaniu.

Szczegółowe informacje o tym, jak używać tych informacji do optymalizacji zapytań, znajdziesz w artykule Optymalizowanie wykonywania zapytań.

Oto przykład drzewa wykonania:

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

Tree:
• Compute
|  $out_1: map_set($record_1, "__id__", $__id___1, "__key__", unset)
|  is query result: true
|
|  Execution:
|   records returned: 35
|   latency: 204.87 ms (local 7.64 ms)
|
└── • Compute
    |  $__id___1: _id($__key___2)
    |
    |  Execution:
    |   records returned: 35
    |   latency: 197.23 ms (local 2.04 ms)
    |
    └── • MajorSort
        |  fields: [$v_5 ASC]
        |  output: [$__key___2, $record_1]
        |
        |  Execution:
        |   records returned: 35
        |   latency: 195.20 ms (local 28.42 ms)
        |   peak memory usage: 45.56 KiB (46,656 B)
        |
        └── • Compute
            |  $v_5: offset($v_4, 0L)
            |
            |  Execution:
            |   records returned: 35
            |   latency: 166.78 ms (local 14.84 ms)
            |
            └── • Compute
                |  $v_4: sortPaths(array($date_placed_1), [date_placed ASC])
                |
                |  Execution:
                |   records returned: 35
                |   latency: 151.94 ms (local 5.43 ms)
                |
                └── • TableScan
                       source: **/orders
                       order: STABLE
                       filter: $eq($user_id_1, 1,234)
                       output bindings: {$__key___2=row().__key__, $date_placed_1=row().date_placed, $record_1=row[* - { __create_time__, __update_time__ }](), $user_id_1=row().user_id}
                       output: [$__key___2, $date_placed_1, $record_1]

                       Execution:
                        records returned: 35
                        latency: 146.50 ms
                        data bytes returned: 3.25 KiB (3,325 B)
                        post-filtered rows: 230
                        records scanned: 265
                        data bytes read: 24.58 KiB (25,175 B)

Co dalej?