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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 查詢優先順序
透過 Amazon Redshift，即可使用工作負載管理 (WM) 來管理並行查詢和工作負載之間的查詢優先順序和資源配置。下列各節詳細說明如何設定 WM 查詢佇列、定義像是記憶體配置和並行擴展等佇列屬性，以及實作根據您的工作負載需求量身打造的優先順序規則。
並非所有查詢都具有相同的重要性，通常某個工作負載或某一組使用者的效能會比較重要。如果您已啟用[自動 WLM](automatic-wlm.md)，則可透過設定優先順序值來定義查詢在工作負載中的相對重要性。為佇列指定優先順序，與佇列關聯的所有查詢就會繼承其優先順序。將使用者群組和查詢群組對應到佇列，即可將查詢關聯至佇列。您可以設定以下優先順序 (從最高優先順序到最低優先順序列出)：
1. `HIGHEST`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `LOWEST`
當優先順序不同的查詢爭用相同資源時，管理員使用這些優先順序來顯示其工作負載的相對重要性。Amazon Redshift 會採用優先順序來將查詢放入系統，以及決定分配給查詢的資源量。依預設，查詢的優先順序設定為 `NORMAL`。
超級使用者可使用一個額外的優先順序 `CRITICAL`，這是比 `HIGHEST` 更高的優先順序。若要設定此優先順序，您可使用函數 [CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md)、[CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) 和 [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md)。若要將使用這些函數的許可授予給資料庫使用者，您可以建立預存程序並授予許可給使用者。如需範例，請參閱 [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md)。
**注意**
一次只能執行一個 `CRITICAL` 查詢。
復原一律以 CRITICAL 優先順序執行。
我們使用一個範例，其中擷取、轉換、載入 (ETL) 工作負載的優先順序高於分析工作負載的優先順序。ETL 工作負載每六個小時執行一次，而分析工作負載全天執行。當只有分析工作負載在叢集上執行時，它可取得整個系統，產生高輸送量和最佳的系統使用率。不過，當 ETL 工作負載啟動時，它會取得正確的權限，因為它具有更高的優先順序。做為 ETL 工作負載執行的查詢可優先獲得許可，在被核准之後也能獲得優先資源分配。因此，無論系統上有哪些其他項目正在執行，ETL 工作負載都能如預期地執行。因此，它能提供可預測的效能，以及讓管理員為其商業使用者提供服務水準協議 (SLA)。
在指定叢集中，高優先順序工作負載能獲得可預測的效能，代價是其他較低優先順序的工作負載。較低優先順序的工作負載可能會執行得更久，因為它們的查詢要等候較重要的查詢先完成。或者，當它們與較高優先順序的查詢同時執行時，所獲得的資源較少，所以要執行得更久。較低優先順序的查詢不會面臨資源耗盡，只是以較慢的速度取得進展。
在前面的範例中，管理員可以為分析工作負載啟用[並行擴展](concurrency-scaling.md)。這麼做可以在即使 ETL 工作負載以高優先順序執行時，也能讓分析工作負載保持輸送量。
## 設定佇列優先順序
如果您已啟用自動 WLM，則每個佇列都具有優先順序值。查詢會根據使用者群組和查詢群組而路由到佇列。從將佇列優先順序設定為 `NORMAL` 開始。請根據與佇列之使用者群組和查詢群組關聯的工作負載，設定更高或更低的優先順序。
您可以在 Amazon Redshift 主控台上變更佇列的優先順序。在 Amazon Redshift 主控台上，**工作負載管理**頁面會顯示佇列並啟用佇列屬性的編輯，例如**優先順序**。若要使用 CLI 或 API 操作來設定優先順序，請使用 `wlm_json_configuration` 參數。如需詳細資訊，請參閱《Amazon Redshift 管理指南》**中的[設定工作負載管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
下列 `wlm_json_configuration` 範例定義三個使用者群組 (`ingest`、`reporting` 和 `analytics`)。來自這些群組的使用者所提交的查詢分別以 `highest`、`normal` 和 `low` 的優先順序執行。
```
[
{
"user_group": [
"ingest"
],
"priority": "highest",
"queue_type": "auto"
},
{
"user_group": [
"reporting"
],
"priority": "normal",
"queue_type": "auto"
},
{
"user_group": [
"analytics"
],
"priority": "low",
"queue_type": "auto",
"auto_wlm": true
}
]
```
## 使用查詢監控規則變更查詢優先順序
查詢監視規則 (QMR) 可讓您根據查詢執行時的行為，來變更查詢的優先順序。您可以在 QMR 述詞中指定優先順序屬性以及動作，來執行此作業。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。
例如，您可以定義規則，來取消任何分類為 `high` 優先順序且執行超過 10 分鐘的查詢。
```
"rules" :[
{
"rule_name":"rule_abort",
"predicate":[
{
"metric_name":"query_cpu_time",
"operator":">",
"value":600
},
{
"metric_name":"query_priority",
"operator":"=",
"value":"high"
}
],
"action":"abort"
}
]
```
另一個範例是定義規則以將目前優先順序為 `normal` 且溢出超過 1 TB 到磁碟之任何查詢的優先順序變更為 `lowest`。
```
"rules":[
{
"rule_name":"rule_change_priority",
"predicate":[
{
"metric_name":"query_temp_blocks_to_disk",
"operator":">",
"value":1000000
},
{
"metric_name":"query_priority",
"operator":"=",
"value":"normal"
}
],
"action":"change_query_priority",
"value":"lowest"
}
]
```
## 監控查詢優先順序
若要顯示等待中和執行中查詢的優先順序，請檢視 stv\$1wlm\$1query\$1state 系統資料表中的 `query_priority` 欄。
```
query | service_cl | wlm_start_time | state | queue_time | query_priority
---------+------------+----------------------------+------------------+------------+----------------
2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest
2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest
2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High
2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest
2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest
2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High
2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal
2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest
```
若要列出已完成查詢的優先順序，請檢視 stl\$1wlm\$1query 系統資料表中的 `query_priority` 欄。
```
select query, service_class as svclass, service_class_start_time as starttime, query_priority
from stl_wlm_query order by 3 desc limit 10;
```
```
query | svclass | starttime | query_priority
---------+---------+----------------------------+----------------------
2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal
2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest
2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest
2723244 | 103 | 2019-06-24 18:14:50.719241 | High
2723243 | 101 | 2019-06-24 18:14:50.699325 | Low
2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest
2723239 | 101 | 2019-06-24 18:14:50.668535 | Low
2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest
2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest
```
為了最佳化工作負載的輸送量，Amazon Redshift 可能會修改使用者所提交查詢的優先順序。Amazon Redshift 會使用進階機器學習演算法來判斷此最佳化何時有利於您的工作負載，並在符合下列所有條件時自動套用。
+ 自動 WLM 已啟用。
+ 僅會定義一個 WLM 佇列。
+ 您尚未定義用來設定查詢優先順序的查詢監控規則 (QMR)。此類規則包括 QMR 指標 `query_priority` 或 QMR 動作 `change_query_priority`。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。