改善 查詢效能 - Amazon Redshift

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

改善 查詢效能

以下是影響查詢效能的一些常見問題,以及其診斷和解決方式的指示。

資料表統計資訊遺漏或過時

如果資料表統計資料遺漏或過時,您可能會看見下列:

  • EXPLAIN 命令結果中有警告訊息。

  • STL_ALERT_EVENT_LOG 中遺漏統計資料提醒事件。如需詳細資訊,請參閱 檢閱查詢提醒

若要修正此問題,請執行 ANALYZE

巢狀迴圈

如果出現巢狀迴路,您可能會在 STL_ALERT_EVENT_LOG 中看見巢狀迴路提醒事件。您也可以透過執行識別具有巢狀迴圈的查詢中的查詢,來識別此類型的事件。如需詳細資訊,請參閱 檢閱查詢提醒

若要修正此問題,請檢閱您的查詢以取得交叉聯結並在可能時加以移除。交叉聯結是沒有聯結條件的聯結,會造成兩個資料表的笛卡兒乘積。它們通常會以巢狀迴路聯結的形式執行,這是可能的聯結類型中最慢的。

雜湊聯結

如果出現雜湊聯結,您可能會看見下列:

  • 查詢計畫中的雜湊和雜湊聯結操作。如需詳細資訊,請參閱 分析查詢計劃

  • 區段中的 HJOIN 步驟具有 SVL_QUERY_SUMMARY 中最高的 maxtime 值。如需詳細資訊,請參閱 使用 SVL_QUERY_SUMMARY 檢視

若要修正此問題,您可以採取兩個方法:

  • 如果可能,重新寫入查詢以使用合併聯結。指定同時為散發索引鍵和排序索引鍵的聯結資料欄即可執行此動作。

  • 如果 SVL_QUERY_SUMMARY 的 HJOIN 步驟的資料列欄位相較於查詢中最終 RETURN 步驟中的資料列值有非常高的值,請檢查您是否可以重新寫入查詢以在唯一資料欄上聯結。當查詢未在唯一資料欄上聯結時,例如主要索引鍵,它會增加聯結中牽涉的資料列數量。

幽靈資料列或未遞交的資料列

如果出現幽靈資料列或未遞交的資料列,您可能會在 STL_ALERT_EVENT_LOG 看見提醒事件,指出過量的幽靈資料列。如需詳細資訊,請參閱 檢閱查詢提醒

若要修正此問題,您可以採取兩個方法:

  • 檢查LOADOR選項卡,用於對任何查詢表進行活動加載操作。如果您看見作用中的載入操作,採取動作之前,請等候那些操作完成。

  • 如果沒有作用中載入操作,請在查詢資料表上執行 VACUUM 來移除刪除的資料列。

未排序或排序錯誤的資料列

如果出現未排序或排序錯誤的資料列,您可能會在 STL_ALERT_EVENT_LOG 中看見非常高的篩選條件提醒事件。如需詳細資訊,請參閱 檢閱查詢提醒

您也可以透過執行 識別具有資料扭曲或未排序資料列的資料表 中的查詢,查看您的查詢中是否任何資料表有大型未排序的區域。

若要修正此問題,您可以採取兩個方法:

  • 在查詢資料表上執行 VACUUM 來重新排序資料列。

  • 檢閱查詢資料表上的排序索引鍵,以查看是否有可以進行的任何改善。請記得評估此查詢的效能與其他重要查詢和整體系統的效能,再進行任何變更。如需詳細資訊,請參閱 使用排序索引鍵

次佳資料分佈

如果資料配送為次佳,您可能會看見下列:

  • STL_ALERT_EVENT_LOG 中出現序列執行、大型播送或大型配送提醒事件。如需詳細資訊,請參閱 檢閱查詢提醒

  • 針對指定步驟,配量未處理大約相同數量的資料列。如需詳細資訊,請參閱 使用 SVL_QUERY_REPORT 檢視

  • 針對指定步驟,配量未耗費大約相同的時間量。如需詳細資訊,請參閱 使用 SVL_QUERY_REPORT 檢視

如果前述中無一成立,您也可以透過執行 識別具有資料扭曲或未排序資料列的資料表 中的查詢,查看您的查詢中是否有任何資料表有資料偏度。

若要解決此問題,請參審查查詢中資料表的分佈樣式,並查看是否可以進行任何改善。請記得評估此查詢的效能與其他重要查詢和整體系統的效能,再進行任何變更。如需詳細資訊,請參閱 使用數據分配樣式

配置給查詢的記憶體不足

如果對您的查詢配置了不足的記憶體,您可能會在 SVL_QUERY_SUMMARY 中看見某個步驟的 is_diskbased 值為 true。如需詳細資訊,請參閱 使用 SVL_QUERY_SUMMARY 檢視

若要修正此問題,請透過暫時增加它所使用查詢位置的數量,為查詢配置更多記憶體。工作負載管理 (WLM) 會在查詢佇列中預留位置,大約等同於為佇列設定的並行層級。例如,具有並行層級 5 的佇列有 5 個位置。指派給佇列的記憶體會平均配置到每個位置。對一個查詢指派數個位置可讓該查詢存取所有那些位置的記憶體。如需如何暫時增加查詢位置的詳細資訊,請參閱wlm_query_slot_count

次佳的 WHERE 子句

如果您的 WHERE 子句造成過度的資料表掃描,您可能會在 SVL_QUERY_SUMMARY 中具有最高 maxtime 值的區段中看見 SCAN 步驟。如需詳細資訊,請參閱 使用 SVL_QUERY_SUMMARY 檢視

若要修正此問題,請根據最大資料表的主要排序資料欄,將 WHERE 子句新增至查詢。這種方法可縮短降低掃描時間。如需詳細資訊,請參閱 Amazon Redshift 設計資料表的最佳實務

不足的限制性述詞

如果您的查詢有不足的限制性述詞,您可能會在 SVL_QUERY_SUMMARY 中具有最高 maxtime 值的區段中看見 SCAN 步驟,其相較於查詢中最終 RETURN 步驟中的 rows 值具有非常高的 rows 值。如需詳細資訊,請參閱 使用 SVL_QUERY_SUMMARY 檢視

若要修正此問題,請嘗試新增述詞至查詢,或讓現有述詞更具限制性來縮小列輸出。

非常大的結果集

如果您的查詢返回非常大的結果集,請考慮重新寫入查詢,以使用UNLOAD將結果寫入 Amazon S3。此方式藉由利用平行處理,有效改善 RETURN 步驟的效能。如需檢查非常大型結果集的詳細資訊,請參閱使用 SVL_QUERY_SUMMARY 檢視

大型 SELECT 清單

如果您的查詢有異常大的 SELECT 清單,您可能會在 SVL_QUERY_SUMMARY 中看見相對於 (相較於其他步驟) 任何步驟的 bytes 值來得高的 rows 值。這個高 bytes 值可能是您正選取許多資料欄的指標。如需詳細資訊,請參閱 使用 SVL_QUERY_SUMMARY 檢視

若要修正此問題,請檢閱您要選取的資料欄,並查看是否可移除任何項目。