使用 SVL_QUERY_SUMMARY 檢視 - Amazon Redshift

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 SVL_QUERY_SUMMARY 檢視

若要使用 依串流分析查詢摘要資訊SVL_QUERY_SUMMARY，請執行下列動作：

  1. 執行下列查詢來判斷您的查詢 ID：

    select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;

    在 substring 欄位中檢查截斷的查詢文字，判斷代表您的查詢的 query 值。如果您已執行查詢超過一次，請使用來自具有較低 query 值資料列的 elapsed 值。那是編譯版本的資料列。如果您正在執行許多查詢，您可以提高用於確保查詢包含的LIMIT子句所使用的值。

  2. 從 SVL_QUERY_SUMMARY 選取查詢的資料列。依串流、區段和步驟排列結果：

    select * from svl_query_summary where query = MyQueryID order by stm, seg, step;

    以下是結果範例。

    SVL_QUERY_SUMMARY 中資料列的範例結果，符合指定的查詢。

  3. 使用將查詢計劃映射到查詢摘要中的資訊，將步驟與查詢計畫中的操作映射。它們的資料列和位元組應該具有大約相同的值 (查詢計畫中的資料列 * 寬度)。如果不同，請參閱資料表統計資訊遺漏或過時以取得建議的解決方案。

  4. 查看任何步驟的 is_diskbased 欄位是否具有 t (true) 值。如果系統沒有為查詢處理配置足夠的記憶體，雜湊、彙整和排序為可能將資料寫入至磁碟的運算子。

    如果 is_diskbased 為 true，請參閱配置給查詢的記憶體不足以取得建議的解決方案。

  5. 檢閱label欄位值，並查看步驟中是否有 AGG-DIST-AGG序列。出現它表示兩個步驟彙整，其代價高昂。若要修正此問題，請變更 GROUP BY 子句以使用分發金鑰 （第一個金鑰，如果有多個金鑰）。

  6. 檢閱每個區段的 maxtime 值 (區段中的所有步驟是相同的)。識別具有最高 maxtime 值的區段，並檢閱此區段中下列運算子的步驟。

    注意

    高的 maxtime 值並不一定代表區段有問題。雖然值很高，但該區段可能並未耗費大量時間處理。串流中的所有區段會同時開始計時。不過，部分下游區段必須等到取得來自上游的資料後才能執行。此影響可能使得它們看起來耗費了長時間，因為其 maxtime 值將同時包含等候時間和處理時間。

    • BCAST 或 DIST：在這些情況下，高maxtime值可能是重新分發大量資料列的結果。如需建議的解決方案，請參閱次佳資料分佈。

    • HJOIN （hash join）：如果與RETURN查詢中最後一個步驟的值相比，該步驟在rows欄位中具有非常高rows的值，請參閱 雜湊聯結 以取得建議的解決方案。

    • SCAN/SORT：尋找聯結步驟前的步驟SCANMERGE順序 SCAN、SORT、、。這個模式指出未排序的資料會經過掃描、排序，然後與資料表排序的區域合併。

      看看相較於查詢中最後一個SCAN步驟中的資料列值，該RETURN步驟的資料列值是否有極高的值。這個模式指出執行引擎正在掃描稍後將捨棄的資料列，這樣做缺乏效率。如需建議的解決方案，請參閱不足的限制性述詞。

      如果SCAN步驟maxtime的值很高，請參閱 次佳WHERE子句 以取得建議的解決方案。

      如果SORT步驟rows的值不是零，請參閱 未排序或排序錯誤的資料列 以取得建議的解決方案。

  7. 檢閱最後一個步驟之前 5–10 RETURN 個步驟的 rows和 bytes值，以了解傳回用戶端的資料量。此程序可以是一門藝術。

    例如，在以下範例查詢摘要中，第三個PROJECT步驟提供 rows值，但不是 bytes值。透過查看具有相同rows值的 的上述步驟，您可以找到同時提供資料列和位元組資訊SCAN的步驟。

    以下是範例結果。

    查詢摘要結果中的資料列，這是包含資料列和位元組資訊SCAN的步驟。

    如果您要傳回異常大的資料量，請參閱非常大的結果集以取得建議的解決方案。

  8. 相較於其他步驟，查看 bytes 值是否相對於任何步驟中的 rows 值來得高。這個模式可能指出您正選取許多資料欄。如需建議的解決方案，請參閱大型SELECT清單。