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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 實作手動 WLM
使用手動 WLM，您可以修改 WLM 組態來為長期執行的查詢和短期執行的查詢建立個別的佇列，以管理系統效能和改善使用者的感受。
當使用者在 Amazon Redshift 中執行查詢時，會將查詢路由至查詢佇列。每個查詢佇列包含一些查詢槽。每個佇列都配置有叢集的一部分可用的記憶體。佇列的記憶體再分配給佇列的查詢槽。您可讓 Amazon Redshift 以自動 WLM 來管理查詢並行。如需詳細資訊，請參閱[實作自動 WLM](automatic-wlm.md)。
或者，您可以設定每個查詢佇列的 WLM 屬性。這麼做可以指定各個槽分配記憶體的方式，以及在執行期將查詢路由至特定佇列的方式。您也可以設定 WLM 屬性來取消長時間執行的查詢。
根據預設，Amazon Redshift 會設定以下查詢佇列：
+ **一個超級使用者佇列**
超級使用者佇列會保留給超級使用者專用，因此無法進行設定。只有在需要執行會影響系統的查詢，或基於故障診斷目的，才應該使用此佇列。例如，當您需要取消使用者長期執行的查詢，或需要將使用者新增至資料庫時，請使用此佇列。請勿用來執行例行性查詢。此佇列不會出現主控台，而是在資料庫的系統資料表中以第五個佇列出現。若要在超級使用者佇列中執行查詢，使用者必須以超級使用者身分登入，且必須使用預先定義的 `superuser` 查詢群組來執行查詢。
+ **一個預設使用者佇列**
預設佇列最初會設定為同時執行五個查詢。當您使用手動 WLM 時，您可以變更預設佇列的並行、逾時和記憶體配置屬性，但無法指定使用者群組或查詢群組。預設佇列必須是 WLM 組態中的最後佇列。任何未路由至其他佇列的查詢會在預設佇列中執行。
查詢佇列定義於 WLM 組態。在一或多個可以與叢集相關聯的參數群組中，WLM 組態是可編輯的參數 (`wlm_json_configuration`)。如需詳細資訊，請參閱《Amazon Redshift 管理指南》**中的[設定工作負載管理](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)。
您可以將更多查詢佇列新增至預設 WLM 組態，最多總共八個使用者佇列。您可以為每個查詢佇列設定下列項目：
+ 並行擴展模式
+ 並行層級
+ 使用者群組
+ 查詢群組
+ 要使用的 WLM 記憶體百分比
+ WLM 逾時
+ WLM 查詢佇列跳轉
+ 查詢監控規則
## 並行擴展模式
當並行擴展啟用時，當您需要更多叢集容量以執行增加的並行讀取及寫入查詢時，Amazon Redshift 將會自動新增額外的叢集容量。使用者會看到最新資料，無論查詢是執行於主要叢集或並行擴展叢集。
您可藉由設定 (WLM) 佇列來管理要將哪些查詢傳送至並行擴展叢集。當您為佇列啟用並行擴展時，合格查詢將傳送到並行擴展叢集，而非在佇列中等待。如需詳細資訊，請參閱[並行擴展](concurrency-scaling.md)。
## 並行層級
佇列中的查詢可以同時執行，直到達到該佇列已定義的 WLM 查詢槽計數 (或*並行*層級) 為止。後續的查詢需要在佇列中等待。
**注意**
WLM 並行層級不同於可對叢集建立的並行使用者連線數。如需詳細資訊，請參閱《Amazon Redshift 管理指南》**中的[連線到叢集](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html)。
在自動 WLM 組態中 (建議使用)，並行層級設為**自動**。Amazon Redshift 會動態地將記憶體配置給查詢，然後決定要同時執行多少個查詢。這是基於執行中和佇列查詢所需的資源。自動 WLM 無法設定。如需詳細資訊，請參閱[實作自動 WLM](automatic-wlm.md)。
在手動 WLM 組態中，Amazon Redshift 會以靜態方式為每個佇列配置固定數量的記憶體。佇列的記憶體會在查詢插槽之間平均分割。說明如下，如果佇列分配到 20％ 的叢集記憶體，並且具有 10 個插槽，則每個查詢都會分配到 2％ 的叢集記憶體。無論同時執行的查詢數目為何，記憶體配置都會保持固定。因為此固定的記憶體配置，如果查詢在槽計數為 5 時可完全在記憶體中執行，當槽計數增加到 20 時，就可能將中間結果寫入磁碟。在這種情況下，每個查詢的佇列記憶體共用會從 1/5 減少到 1/20。增加的磁碟 I/O 會降低效能。
所有使用者定義佇列上的插槽計數上限為 50 個。這會限制所有佇列 (包括預設佇列) 的總插槽數。唯一不受限制限制的佇列是保留的超級使用者佇列。
根據預設，手動 WLM 佇列的並行層級為 5。在某些情況下，較高的並行層級可能有利於工作負載，例如：
+ 如果許多較小的查詢被迫等待長期執行的查詢，請建立槽計數較高的另一個佇列，並將較小的查詢指派至該佇列。並行層級較高的佇列配置給每個查詢槽的記憶體較少，但較小的查詢所需的記憶體不多。
**注意**
如果您啟用短期查詢加速 (SQA)，WLM 會自動優先排定短期查詢，而長期執行查詢的優先順序會較低，所以您不需要為大部分工作流程的短期查詢準備另一個佇列。如需詳細資訊，請參閱[短期查詢加速](wlm-short-query-acceleration.md)。
+ 如果您有多個查詢，每一個都會存取單一配量上的資料，請設定個別的 WLM 佇列以同時執行這些查詢。Amazon Redshift 會將並行查詢指派給不同配量，以便在多個配量上平行執行多個查詢。例如，假設查詢是在散發索引鍵上搭配述詞執行的簡單彙總，則查詢的資料會位於單一配量上。
### 一個手動 WLM 範例
此範例是一個簡單的手動 WLM 案例，用來說明插槽和記憶體的配置方式。您可以使用三個佇列來實作手動 WLM，這些佇列如下：
+ *資料擷取佇列* – 這是針對擷取資料而設定的。這會分配 20％ 的叢集記憶體，並且具有 5 個插槽。隨後，5 個查詢可以在佇列中同時運行，並且每個查詢會分配到 4％ 的記憶體。
+ *資料科學家佇列* - 這是專為記憶體密集型查詢而設計的。這會分配 40％ 的叢集記憶體，並且具有 5 個插槽。隨後，5 個查詢可以同時運行，並且每個查詢會分配到 8％ 的記憶體。
+ *預設佇列* – 這是針對組織中大多數使用者所設計的。這包括銷售和會計群組，這些群組通常具有不複雜的簡短或中型執行查詢。它會分配到 40％ 的叢集記憶體，並且具有 40 個插槽。40 個查詢可以在此佇列中同時執行，而每個查詢會分配到 1％ 的記憶體。這是可配置給此佇列的插槽數目上限，因為所有佇列之間的限制為 50 個。
如果您正在執行自動 WLM，且工作負載需要並行執行 15 個以上的查詢，建議您開啟並行擴展。這是因為將查詢槽計數增加到 15 以上可能會導致系統資源爭用，並限制單一叢集的整體輸送量。使用並行擴展，您可以平行執行數百個查詢，最多可達設定的並行擴展叢集數目。並行擴展叢集數目由 [max\_concurrency\_scaling\_clusters](r_max_concurrency_scaling_clusters.md) 控制。如需並行擴展的相關資訊，請參閱 [並行擴展](concurrency-scaling.md)。
如需詳細資訊，請參閱[查詢效能改善](query-performance-improvement-opportunities.md)。
## 使用者群組
您可以指定每一個使用者群組名稱或使用萬用字元，將一組使用者群組指派給佇列。當所列的使用者群組中有一個成員執行查詢時，該查詢會在相應佇列中執行。可指派給佇列的使用者群組數沒有固定的限制。如需詳細資訊，請參閱[根據使用者群組將查詢指派給佇列](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups)。
## 使用者角色
您可以指定每一個使用者角色名稱或使用萬用字元，將一組使用者角色指派給佇列。當所列的使用者角色中有一個成員執行查詢時，該查詢會在對應的佇列中執行。可指派給佇列的使用者角色數量沒有固定限制。如需詳細資訊，請參閱[根據使用者角色將查詢指派給佇列](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles)。
## 查詢群組
您可以指定每一個查詢群組名稱或使用萬用字元，將一組查詢群組指派給佇列。查詢群組只是一個標籤。在執行時間，您可以將查詢群組標籤指派給一系列查詢。指派給所列之查詢群組的任何查詢會在相應佇列中執行。可指派給佇列的查詢群組數沒有固定的限制。如需詳細資訊，請參閱[將查詢指派給查詢群組](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group)。
## 萬用字元
如果 WLM 佇列組態中啟用萬用字元，您可以個別地或利用 Unix shell 樣式的萬用字元，將使用者群組和查詢群組指派給佇列。模式比對不區分大小寫。
例如，'\*' 萬用字元符合任意數目的字元。因此，如果您將 `dba_*` 新增至佇列的使用者群組清單，任何使用者執行查詢只要是屬於以 `dba_` 為名稱開頭的群組，都指派到該佇列。例如 `dba_admin` 或 `DBA_primary`。'?' 萬用字元符合任何單一字元。因此，如果佇列包含使用者群組 `dba?1`，則名為 `dba11` 和 `dba21` 的使用者群組符合，但 `dba12` 不符。
依預設，萬用字元處於關閉狀態。
## 要使用的 WLM 記憶體百分比
在自動 WLM 組態中，記憶體百分比設為 **auto**。如需詳細資訊，請參閱[實作自動 WLM](automatic-wlm.md)。
在手動 WLM 組態中，若要指定配置給查詢的可用記憶體數量，您可以設定 `WLM Memory Percent to Use` 參數。根據預設，每個使用者定義佇列都配置有相等份額的記憶體，可供使用者定義的查詢使用。例如，假設您有四個使用者定義佇列，則會配置可用記憶體的 25% 給每一個佇列。超級使用者佇列有其自己配置的記憶體，無法修改。若要變更配置，請將記憶體的整數百分比指派給每個佇列，總計最多 100%。任何未配置的記憶體由 Amazon Redshift 管理並可暫時提供給佇列 (如果佇列要求更多記憶體來進行處理)。
例如，假設您設定四個佇列，則可以如下配置記憶體：20%、30%、15%、15%。剩餘 20% 未配置，由服務管理。
## WLM 逾時
WLM 逾時 (`max_execution_time`) 已作廢。這時請改成使用 `query_execution_time` 建立查詢監控規則 (QMR)，以限制查詢的經歷執行時間。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。
若要限制給定的 WLM 佇列中允許查詢使用的時間，您可以設定每個佇列的 WLM 逾時值。逾時參數指定 Amazon Redshift 在取消或轉跳查詢之前，等待查詢開始執行的時間量 (以毫秒為單位)。逾時以查詢執行時間為基礎，不包括在佇列中等待所花的時間。
WLM 會嘗試轉跳 [CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) 陳述式和唯讀查詢，例如 SELECT 陳述式。無法轉跳的查詢會取消。如需詳細資訊，請參閱[WLM 查詢佇列跳轉](wlm-queue-hopping.md)。
WLM 逾時不適用於已達到傳回狀態的查詢。若要檢視查詢的狀態，請參閱 [STV\_WLM\_QUERY\_STATE](r_STV_WLM_QUERY_STATE.md) 系統資料表。COPY 陳述式和維護操作 (例如 ALTER、ANALYZE 和 VACUUM) 不受 WLM 逾時限制。
WLM 逾時的功能類似於 [statement\_timeout](r_statement_timeout.md) 組態參數。差別在於 `statement_timeout` 組態參數適用於整個叢集，而 WLM 逾時是針對 WLM 組態中的單一佇列。
如果也指定 [statement\_timeout](r_statement_timeout.md)，則會使用 statement\_timeout 和 WLM timeout (max\_execution\_time) 之中較小者。
## 查詢監控規則
查詢監控規則會為 WLM 佇列定義以指標為基礎的效能邊界，並指定當查詢超出這些邊界時採取的動作。例如，對於短期執行查詢專用的佇列，您可以建立規則，以將執行時間超過 60 秒的查詢取消。若要追蹤設計不良的查詢，您可以使用另一個規則來記錄含有巢狀迴圈的查詢。如需詳細資訊，請參閱[WLM 查詢監控規則](cm-c-wlm-query-monitoring-rules.md)。