改善 查詢效能

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

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

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

• 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 看見提醒事件，指出過量的幽靈資料列。如需詳細資訊，請參閱 檢閱查詢提醒。

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

• 查看 Amazon Redshift 主控台的載入索引標籤，以瞭解任何查詢資料表上的作用中載入操作。如果您看見作用中的載入操作，採取動作之前，請等候那些操作完成。

• 如果沒有作用中載入操作，請在查詢資料表上執行 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 檢視。

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