Sorgu açıklama aracıyla sorgu yürütmeyi analiz etme

Bu sayfada, bir sorgu yürüttüğünüzde sorgu yürütme bilgilerinin nasıl alınacağı açıklanmaktadır.

Sorgu Açıklama'yı kullanma

Sorgularınızın nasıl yürütüldüğünü anlamak için Query Explain'i kullanabilirsiniz. Bu, sorgularınızı optimize etmek için kullanabileceğiniz ayrıntılar sağlar.

Google Cloud Console veya explain komutu aracılığıyla Query Explain'i kullanabilirsiniz.

Konsol

Sorgu düzenleyicide bir sorgu yürütün ve Açıklama sekmesini açın:

  1. Google Cloud Console'da Veritabanları sayfasına gidin.

    Veritabanları'na gidin

  2. Veritabanları listesinden bir Cloud Firestore veritabanı seçin. Google Cloud Console, söz konusu veritabanı için Firestore Gezgini'ni açar.
  3. Sorgu düzenleyiciye bir sorgu girin ve Çalıştır'ı tıklayın.

  4. Sorgu analizi çıkışını görüntülemek için Açıklama sekmesini tıklayın.

    Konsoldaki Sorguyu Açıklama sekmesi
MongoDB API

MongoDB API'deki Query Explain, Mongo Shell ve Compass gibi araçlarda kullanabileceğiniz explain komutuyla desteklenir.

explain komutu aggregate, find, distinct ve count komutlarıyla desteklenir. Örneğin:

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

Ayrıca, örneğin explain() yöntemini de kullanabilirsiniz:

db.collection.find({QUERY}).explain('executionStats')
Sınırlamalar
Aşağıdaki sınırlamaları ve farklılıkları göz önünde bulundurun:

  • Sorgu Açıklama, imleç döndüren komutları desteklemez. Örneğin, aşağıdaki komutu doğrudan çağırarak açıklama isteme desteklenmez:

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

  • Sorgu Açıklama yalnızca find, aggregate, count, distinct, update, delete ve findAndModify komutlarında desteklenir.

  • Sorgu Açıklama özelliği, executionStats, allPlansExecution ve queryPlanner ayrıntı modlarını destekler.

    • queryPlanner: Sorguyu yürütmeden yalnızca yürütme planını döndürür.
    • executionStats ve allPlansExecution: Faturalandırma, bellek ve yürütme istatistikleriyle birlikte yürütme planını döndürür.

    Ayrıntı modu belirtilmezse kabuk varsayılan olarak queryPlanner değerini kullanır. Tam yürütme istatistiklerini görmek için executionStats veya allPlansExecution ayrıntı modunu belirtmeniz gerekir.

Analiz

Sorgu Açıklama'nın çıktısı iki ana bileşen içerir: Özet İstatistikler ve Yürütme Ağacı. Örnek olarak şu sorguyu ele alalım:

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

Özet İstatistikler

Açıklanan çıkışın üst kısmında, yürütme istatistiklerinin özeti yer alır. Bir sorgunun yüksek gecikme süresine veya maliyete sahip olup olmadığını belirlemek için bu istatistikleri kullanın. Ayrıca, sorgunuzun bellek sınırlarına ne kadar yaklaştığını gösteren bellek istatistikleri de içerir.

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

Yürütme Ağacı

Yürütme ağacı, sorgu yürütmeyi bir dizi düğüm olarak tanımlar. En alttaki düğümler (yaprak düğümler), sorgu yanıtı oluşturmak için ağaçta yukarı doğru ilerleyerek depolama katmanından veri alır.

Her yürütme düğümüyle ilgili ayrıntılar için Yürütme referansı başlıklı makaleyi inceleyin.

Sorgularınızı optimize etmek için bu bilgileri nasıl kullanacağınızla ilgili ayrıntılar için Sorgu yürütmeyi optimize etme başlıklı makaleyi inceleyin.

Aşağıda, yürütme ağacına dair bir örnek verilmiştir:

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)

Sırada ne var?