تجزیه‌وتحلیل اجرای پُرسمان با Query Explain

این صفحه نحوه بازیابی اطلاعات اجرای پُرسمان را هنگام اجرای پُرسمان شرح می‌دهد.

استفاده از Query Explain

می‌توانید از Query Explain برای درک نحوه اجرای پُرسمان‌هایتان استفاده کنید. این گزارش جزئیاتی ارائه می‌دهد که می‌توانید از آن‌ها برای بهینه‌سازی پُرسمان‌هایتان استفاده کنید.

می‌توانید از Query Explain ازطریق کنسول Google Cloud یا فرمان explain استفاده کنید.

کنسول

پرسمانی را در «ویرایشگر پرسمان» اجرا کنید و برگه توضیح را باز کنید:

  1. در کنسول Google Cloud، به صفحه پایگاه‌های داده بروید.

    رفتن به پایگاه‌های داده

  2. از فهرست پایگاه‌های داده، پایگاه داده Cloud Firestore را انتخاب کنید. کنسول Google Cloud‏ Firestore Explorer را برای آن پایگاه داده باز می‌کند.
  3. پُرسمانی را در ویرایشگر پُرسمان وارد کنید و روی اجرا کلیک کنید.
  4. روی برگه توضیح کلیک کنید تا برونداد تحلیل پُرسمان را مشاهده کنید.

    برگه «توضیح پُرسمان» در کنسول
MongoDB API

«توضیح پُرسمان» در MongoDB API ازطریق فرمان explain پشتیبانی می‌شود که می‌توانید از آن در ابزارهایی مثل Mongo Shell و Compass استفاده کنید.

فرمان explain با فرمان‌های aggregate، find، distinct، و count پشتیبانی می‌شود، برای مثال:

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

همچنین می‌توانید از روش explain() استفاده کنید، برای مثال:

db.collection.find({QUERY}).explain('executionStats')
محدودیت‌ها
به محدودیت‌ها و تفاوت‌های زیر توجه کنید:
  • Query Explain از فرمان‌هایی که مکان‌نما را برمی‌گردانند پشتیبانی نمی‌کند. برای مثال، فراخوانی explain با فراخوانی مستقیم فرمان زیر پشتیبانی نمی‌شود:

    db.collection.aggregate(..., explain: true)
  • Query Explain فقط در فرمان‌های find، aggregate، count، distinct، update، delete، و findAndModify پشتیبانی می‌شود.

  • Query Explain از حالت‌های سطح جزئیات executionStats،‏ allPlansExecution، و queryPlanner پشتیبانی می‌کند.

    • queryPlanner: فقط طرح اجرا را برمی‌گرداند، بدون اینکه پُرسمان را اجرا کند،
    • executionStats و allPlansExecution: طرح اجرا را به‌همراه آمار صورت‌حساب، حافظه، و اجرا برمی‌گرداند.

    اگر حالت سطح جزئیات مشخص نشده باشد، پوسته به‌طور پیش‌فرض روی queryPlanner تنظیم می‌شود. برای دیدن آمار کامل اجرا، باید حالت سطح جزئیات executionStats یا allPlansExecution را مشخص کنید.

Analysis

خروجی Query Explain شامل دو مؤلفه اصلی است: «آمار خلاصه» و «درخت اجرا». این پُرسمان را به‌عنوان نمونه درنظر بگیرید:

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

آمار خلاصه

بالای برونداد توضیح‌داده‌شده حاوی خلاصه‌ای از آمار اجرا است. از این آمار برای تعیین اینکه آیا پُرسمان تأخیر یا هزینه بالایی دارد استفاده کنید. همچنین حاوی آمار حافظه است که به شما اطلاع می‌دهد پُرسمان شما چقدر به محدودیت‌های حافظه نزدیک است.

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

درخت اجرا

درخت اجرا، اجرای پُرسمان را به‌صورت مجموعه‌ای از گره‌ها توصیف می‌کند. گره‌های پایینی (گره‌های برگ) داده‌ها را از لایه ذخیره‌سازی بازیابی می‌کنند که برای تولید پاسخ پُرسمان، درخت را به‌سمت بالا طی می‌کند.

برای جزئیات مربوط به هر گره اجرا، به مرجع اجرا مراجعه کنید.

برای جزئیات درباره نحوه استفاده از این اطلاعات برای بهینه‌سازی پُرسمان‌هایتان، بهینه‌سازی اجرای پُرسمان را ببینید.

در زیر نمونه‌ای از درخت اجرا آورده شده است:

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)

حالا چه می‌شود