使用 SVL_QUERY_SUMMARY 檢視 - Amazon Redshift

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

使用 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;
  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):如果有問題的步驟在rows字段與rows值,請參閲雜湊聯結瞭解推薦的解決方案。

    • 掃描/排序:只需查找掃描,排序,掃描,合併步驟序列之前連接步驟。這個模式指出未排序的資料會經過掃描、排序,然後與資料表排序的區域合併。

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

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

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

  7. rowsbytes值,以取得最終 RETURN 步驟之前的 5—10 步驟,以取得返回給用户端。此程序可以是一門藝術。

    例如,在下列查詢摘要中,您可以看到第三個 PROJECT 步驟提供 rows 值而非 bytes 值。查看前述步驟來找到具有相同 rows 值的步驟,您會找到同時提供資料列和位元組資訊的 SCAN 步驟:

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

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