Abfrageausführung mit Query Explain analysieren

Auf dieser Seite wird beschrieben, wie Sie Informationen zur Abfrageausführung abrufen, wenn Sie eine Abfrage ausführen.

„Query Explain“ verwenden

Mit „Query Explain“ können Sie nachvollziehen, wie Ihre Abfragen ausgeführt werden. Hier finden Sie Details, mit denen Sie Ihre Abfragen optimieren können.

Sie können Query Explain über die Google Cloud -Konsole oder den explain-Befehl verwenden.

Console

Führen Sie eine Abfrage im Abfrageeditor aus und öffnen Sie den Tab Erklärung:

  1. Rufen Sie in der Google Cloud Console die Seite Datenbanken auf.

    Zur Seite „Datenbanken“

  2. Wählen Sie aus der Liste der Datenbanken eine Firestore-Datenbank mit MongoDB-Kompatibilität aus. In der Google Cloud Console wird der Firestore Explorer für diese Datenbank geöffnet.
  3. Geben Sie eine Abfrage in den Abfrageeditor ein und klicken Sie auf Ausführen.

  4. Klicken Sie auf den Tab Erklärung, um die Ausgabe der Abfrageanalyse aufzurufen.

    Tab „Abfrage erläutern“ in der Console
MongoDB API

„Query Explain“ in der MongoDB API wird über den Befehl explain unterstützt, den Sie in Tools wie Mongo Shell und Compass verwenden können.

Der Befehl explain wird mit den Befehlen aggregate, find, distinct und count unterstützt, z. B.:

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

Sie können auch die Methode explain() verwenden, z. B.:

db.collection.find({QUERY}).explain('executionStats')
Beschränkungen
Beachten Sie die folgenden Einschränkungen und Unterschiede:

  • „Query Explain“ unterstützt keine Befehle, die einen Cursor zurückgeben. Das Aufrufen von „explain“ durch direkten Aufruf des folgenden Befehls wird beispielsweise nicht unterstützt:

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

  • „Query Explain“ wird nur für die Befehle find, aggregate, count, distinct, update, delete und findAndModify unterstützt.

  • Query Explain unterstützt die Ausführlichkeitsmodi executionStats, allPlansExecution und queryPlanner.

    • queryPlanner: Gibt nur den Ausführungsplan zurück, ohne die Abfrage auszuführen.
    • executionStats und allPlansExecution: Gibt den Ausführungsplan zusammen mit Abrechnungs-, Speicher- und Ausführungsstatistiken zurück.

    Wenn kein Ausführlichkeitsmodus angegeben ist, wird standardmäßig queryPlanner verwendet. Wenn Sie die vollständigen Ausführungsstatistiken sehen möchten, müssen Sie den Ausführlichkeitsmodus executionStats oder allPlansExecution angeben.

Analyse

Die Ausgabe von „Query Explain“ enthält zwei Hauptkomponenten: die Zusammenfassungsstatistiken und den Ausführungsbaum. Betrachten Sie die folgende Abfrage als Beispiel:

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

Zusammenfassende Statistiken

Oben in der erläuterten Ausgabe finden Sie eine Zusammenfassung der Ausführungsstatistiken. Anhand dieser Statistiken können Sie feststellen, ob eine Abfrage eine hohe Latenz oder hohe Kosten verursacht. Er enthält auch Speicherstatistiken, mit denen Sie sehen können, wie nahe Ihre Abfrage an den Speicherlimits liegt.

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

Ausführungsstruktur

Die Ausführungsstruktur beschreibt die Abfrageausführung als eine Reihe von Knoten. Die unteren Knoten (Blattknoten) rufen Daten aus der Speicherebene ab, die den Baum durchläuft, um eine Antwort auf die Anfrage zu generieren.

Weitere Informationen zu den einzelnen Ausführungsknoten finden Sie in der Ausführungsreferenz.

Weitere Informationen dazu, wie Sie diese Informationen zum Optimieren Ihrer Abfragen verwenden können, finden Sie unter Abfrageausführung optimieren.

Das folgende Beispiel zeigt einen Ausführungsbaum:

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)

Nächste Schritte