為什麼在 Amazon Redshift 維護後，我的查詢執行時間變長了？

簡短說明

在進行版本升級期間，Amazon Redshift 會清除查詢快取與編譯快取。升級後首次執行查詢時，編譯時間會較長。不過，隨著 Amazon Redshift 重新建立快取，效能會逐漸改善。

並非所有維護時段的動作都會變更 Amazon Redshift 叢集版本。若要識別版本變更，請檢查 SYS_QUERY_HISTORY 資料表中的 redshift_version 欄。

如需有關 Amazon Redshift 中快取類型的詳細資訊，請參閱結果快取與已編譯程式碼。如需更多有關查詢效能的資訊，請參閱影響查詢效能的因素。

解決方法

分析維護前後的查詢效能

識別維護前與維護後執行的查詢。您可以使用查詢監控主控台或 SYS_QUERY_HISTORY 系統檢視表。

若要查詢最近 20 筆使用者查詢，請執行以下查詢：

SELECT * FROM sys_query_history
WHERE user_id>1
ORDER BY start_time desc
limit 20;

在輸出結果中，使用 user_query_hash 欄比較具有相同查詢文字的查詢。或使用 generic_query_hash 來比較查詢文字類似，但查詢文字常值不同的查詢。

若要查看過去 7 天內每次執行特定查詢的記錄，請執行以下查詢：

SELECT * FROM sys_query_history
WHERE user_query_hash = 'ExampleText'
ORDER BY start_time desc;

**注意：**將 ExampleText 替換為查詢雜湊值。

在輸出結果中，請比較不同執行的 compile_time 值。維護後立即執行的查詢，其編譯時間可能會較長。

若要縮短編譯時間，請將關鍵查詢排程在維護後執行，或於非尖峰時段預先執行重要查詢以進行預熱。

**注意：**查詢執行引擎會針對 Java Database Connectivity (JDBC) 與 Microsoft Open Database Connectivity (ODBC) 連線協定分別編譯不同的程式碼。若您有兩個使用不同協定的用戶端，每個用戶端都需要支付首次編譯程式碼的成本。不過，使用相同協定的用戶端會共用快取程式碼。當您使用 JDBC 連線至叢集並執行查詢時，Amazon Redshift 只會為 JDBC 連線儲存快取。若您在使用 ODBC 的用戶端上執行相同查詢，Amazon Redshift 會針對 ODBC 連線產生另一份快取。

疑難排解

有時查詢編譯在維護前後差異不大，但可能發生其他無關的效能問題。請使用查詢與資料庫監控主控台監控指標中的異常高峰。比較編譯時間以找出問題來源。

若未發現高峰但仍遇到問題，請建立支援案例。

相關資訊

SVL_COMPILE