Abfrageausführung mit „Abfrage erläutern“ 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. Sie erhalten so Details, mit denen Sie Ihre Abfragen optimieren können.

Sie können Query Explain über die Google Cloud Console oder den Befehl explain 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 in der Liste der Datenbanken eine Cloud Firestore Datenbank 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 anzusehen.

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

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

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

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. Beispielsweise wird das Aufrufen von „explain“ durch direktes Aufrufen des folgenden Befehls 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 in der Shell 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 die Ausführungsstruktur. Betrachten Sie diese Abfrage als Beispiel:

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

Zusammenfassungsstatistiken

Oben in der erklärten 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. Sie enthält auch Speicherstatistiken, mit denen Sie sehen können, wie nahe Ihre Abfrage an den Speicherlimitsliegt.

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 im Baum nach oben durchlaufen werden, um eine Abfrageantwort zu generieren.

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

Informationen dazu, wie Sie diese Informationen verwenden können, um Ihre Abfragen zu optimieren, finden Sie unter Abfrageausführung optimieren.

Im Folgenden sehen Sie ein Beispiel für eine Ausführungsstruktur:

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