Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

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

# 查詢分析工作流程
<a name="c-query-analysis-process"></a>

如果查詢耗費的時間超過預期，請使用下列步驟來識別並更正可能對查詢效能帶來負面影響的問題。如果您不確定系統中有哪些查詢可能透過效能調校而獲益，請在[識別用於調校的最高候選項目查詢](identify-queries-that-are-top-candidates-for-tuning.md)中執行診斷查詢以開始。

1. 確定您的資料表是根據最佳實務而設計。如需詳細資訊，請參閱[設計資料表的 Amazon Redshift 最佳實務](c_designing-tables-best-practices.md)。

1. 請查看是否可以刪除或封存資料表中任何不需要的資料。例如，假設您的查詢一律鎖定最近 6 個月的資料量，但是您的資料表中有最近 18 個月的資料。在此情況下，您可以刪除或封存較舊的資料，以減少需要掃描和配送的記錄數量。

1. 在查詢中對資料表執行 [VACUUM](r_VACUUM_command.md) 命令，以回收空間和重新排序資料列。如果未排序的區域很大，並且查詢使用聯結或述詞中的排序索引鍵，則執行 VACUUM 有幫助。

1. 在查詢中對資料表執行 [ANALYZE](r_ANALYZE.md) 命令，以確定統計資料是最新的。如果查詢中任何資料表的大小最近有許多變更，則執行 ANALYZE 很有幫助。如果執行完整的 ANALYZE 命令將耗費太長時間，請對單一資料欄執行分析以減少處理時間。此方法仍會更新資料表大小統計資料；資料表大小是查詢計畫中的顯著因素。

1. 確定您的查詢已對每個類型的用戶端執行一次 (根據用戶端使用的連線通訊協定的類型而定)，使得該查詢會經過編譯和快取。這種方法會加速查詢的後續執行。如需詳細資訊，請參閱[影響查詢效能的因素](c-query-performance.md)。

1. 請檢查[STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md)資料表來識別和更正您的查詢的可能問題。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。

1. 執行 [EXPLAIN](r_EXPLAIN.md) 命令來取得查詢計畫，並用它來最佳化查詢。如需詳細資訊，請參閱[分析查詢計劃](c-analyzing-the-query-plan.md)。

1. 使用[SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md)和[SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md)檢視來取得摘要資訊，並用它來最佳化查詢。如需詳細資訊，請參閱[分析查詢摘要](c-analyzing-the-query-summary.md)。

有時應該快速執行的查詢會被強制等候其他長時間執行的查詢完成。在該情況下，對於查詢本身，您可能沒有可改善的項目，但您可以藉由對不同類型的查詢建立和使用查詢佇列來改善整體系統效能。若要獲得您的查詢佇列等候時間的概念，請參閱[檢閱查詢的佇列等候時間](review-queue-wait-times-for-queries.md)。如需設定查詢佇列的相關資訊，請參閱[工作負載管理](cm-c-implementing-workload-management.md)。