Analizowanie wykonywania zapytań za pomocą funkcji Query Explain

Ta strona zawiera informacje o tym, jak pobierać informacje o wykonaniu zapytania.

Korzystanie z funkcji Wyjaśnienie zapytania

Funkcja Wyjaśnienie zapytania pozwala zrozumieć, jak wykonywane są zapytania. Dzięki temu możesz uzyskać szczegółowe informacje, które pomogą Ci zoptymalizować zapytania.

Funkcji Wyjaśnienie zapytania możesz używać w konsoli Google Cloud lub za pomocą polecenia explain.

Konsola

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

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

    Otwórz stronę Bazy danych

  2. Z listy baz danych wybierz bazę danych Cloud Firestore. Konsola Google Cloud otworzy 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

Funkcja Wyjaśnienie zapytania w MongoDB API jest obsługiwana za pomocą explain polecenia, 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śnienie zapytania nie obsługuje poleceń, które zwracają kursor. Na przykład wywołanie funkcji explain przez bezpośrednie wywołanie tego polecenia nie jest obsługiwane:

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

  • Funkcja Wyjaśnienie zapytania jest obsługiwana tylko w przypadku poleceń find, aggregate, count, distinct, update, delete, i findAndModify.

  • Funkcja Wyjaśnienie zapytania 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ślono trybu szczegółowości, powłoka domyślnie używa trybu queryPlanner. Aby wyświetlić pełne statystyki wykonania, musisz określić tryb szczegółowości executionStats lub allPlansExecution.

Analiza

Dane wyjściowe funkcji Wyjaśnienie zapytania zawierają 2 główne komponenty – statystyki podsumowujące i drzewo wykonania. Jako przykład rozważ 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. Użyj tych statystyk, aby sprawdzić, czy zapytanie ma długi czas oczekiwania lub wysoki koszt. Zawierają one też statystyki pamięci, które informują o tym, jak blisko zapytanie jest do 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 masowej, która przechodzi przez drzewo, aby wygenerować odpowiedź na zapytanie.

Szczegółowe informacje o poszczególnych węzłach wykonania, znajdziesz w sekcji Informacje o wykonaniu.

Szczegółowe informacje o tym, jak używać tych informacji do optymalizacji zapytań, zobacz Optymalizowanie wykonania zapytania.

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?