从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://www.amazonaws.cn/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

# WLM 查询监控规则
<a name="cm-c-wlm-query-monitoring-rules"></a>

在 Amazon Redshift 工作负载管理 (WLM) 中，查询监控规则为 WLM 查询定义基于指标的性能界限，并指定在查询超出这些界限时需要采取的操作。例如，对于短时间运行查询专用的队列，您可创建取消运行超过 60 秒的查询的规则。要跟踪设计不佳的查询，您可创建记录包含嵌套循环的查询的其他规则。

您将在工作负载管理 (WLM) 配置中定义查询监控规则。您最多可以为每个队列定义 25 个规则，而且所有队列的限制为 25 个规则。每个规则最多包括三个条件 (即，谓词) 和一个操作。*谓词* 包含指标、比较条件（=、< 或 >）和值。如果满足任何规则的所有谓词，则会触发该规则的操作。可能的规则操作有 log、hop 和 abort，如以下所讨论的。

某个给定队列中的规则只能应用于在该队列中运行的查询。各个规则彼此独立。

WLM 每 10 秒评估一次指标。当查询被自动重写时，Amazon Redshift 会在子查询级别应用查询监控规则。如果在同一时段内触发了多条规则，WLM 会选择具有最严重操作的规则。如果两条规则的操作具有相同的严重性，WLM 会根据规则名称按字母顺序运行规则。如果操作为 hop 或 abort，则将记录操作且从队列中移出查询。如果操作为 log，则查询将继续在队列中运行。WLM 针对每个规则的每个查询仅启用一个 log 操作。如果队列中包含其他规则，这些规则将保持有效。如果操作为 hop 且将查询路由到其他队列，则将应用新队列的规则。有关对特定查询执行的查询监控和跟踪操作的更多信息，请参阅[短查询加速](wlm-short-query-acceleration.md)中的示例集。

当满足规则的所有谓词时，WLM 会在 [STL\_WLM\_RULE\_ACTION](r_STL_WLM_RULE_ACTION.md) 系统表中写入一行。此外，Amazon Redshift 会将当前运行的查询的查询指标记录到 [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md)。已完成的查询的指标存储在 [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md) 中。

**注意**  
对于 Amazon Redshift Serverless，您可以使用 `wlm_json_configuration` 参数来配置查询队列和监控规则。这样，您就可以创建具有不同用户角色、查询组和监控规则的多个队列。有关配置无服务器查询队列的更多信息，请参阅《Amazon Redshift 管理指南》**中的[设置查询队列](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-workgroup-query-queues.html)。

## 定义查询监控规则
<a name="cm-c-wlm-defining-query-monitoring-rules"></a>

您创建作为您的 WLM 配置的一部分的查询监控规则，您可将该规则定义为您集群的参数组定义的一部分。

您可使用 Amazon Web Services 管理控制台或以编程方式使用 JSON 来创建规则。

**注意**  
如果您选择以编程方式创建规则，强烈建议您使用控制台生成包含在参数组定义中的 JSON。有关更多信息，请参阅《Amazon Redshift 管理指南》**中的[创建查询监控规则](https://docs.amazonaws.cn/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)和[使用 Amazon CLI 配置参数值](https://docs.amazonaws.cn/redshift/latest/mgmt/working-with-parameter-groups.html#configure-parameters-using-the-cli)。

要定义查询监控规则，您要指定以下元素：
+ 一个规则名称 – 规则名称必须在 WLM 配置内是唯一的。规则名称最多可包含 32 个字母数字字符或下划线，且不能包含空格或引号。您可以让每个队列有最多 25 个规则，并且所有队列的总限制为 25 个规则。
+ 一个或多个谓词 – 您最多可以为每个规则设置三个谓词。如果满足任何规则的所有谓词，则会触发关联操作。谓词由指标名称、运算符（=、< 或 >）和值定义。示例是 `query_cpu_time > 100000`。有关指标列表以及不同指标值的示例，请参阅本部分中后面的[预置的 Amazon Redshift 的查询监控指标](#cm-c-wlm-query-monitoring-metrics)。
+ 操作 – 如果触发了多个操作，则 WLM 会选择具有最严重操作的规则。可能的操作 (按严重性的升序顺序) 包括：
  + Log – 记录有关 STL\_WLM\_RULE\_ACTION 系统表中查询的信息。在您想要仅写入日志记录时使用 Log 操作。WLM 针对每个规则的每个查询最多创建一个日志。log 操作后，其他规则将保持有效且 WLM 将继续监控查询。
  + Hop（仅适用于手动 WLM）– 记录操作，并让查询跳到下一个匹配的队列中。如果没有其他匹配的队列，则会取消查询。QMR 仅跳过 [CREATE TABLE AS](https://docs.amazonaws.cn/redshift/latest/dg/r_CREATE_TABLE_AS.html) (CTAS )语句和只读查询，例如 SELECT 语句。有关更多信息，请参阅 [WLM 查询队列跳过](wlm-queue-hopping.md)。
  + 中止 – 记录操作并取消查询。QMR 不会停止 COPY 语句和维护操作，例如 ALTER、ANALYZE 和 VACUUM。
  + 更改优先级（仅适用于自动 WLM）– 更改查询的优先级。

要限制查询的运行时，我们建议您创建查询监控规则，而不是使用 WLM 超时。例如，您可以将 `max_execution_time` 设置为 50,000 毫秒，如以下 JSON 代码段所示。

```
"max_execution_time": 50000
```

但我们建议您定义一个等效的查询监控规则。下面的示例演示了将 `query_execution_time` 设置为 50 秒的查询监控规则：

```
"rules": 
[
    {
        "rule_name": "rule_query_execution",
        "predicate": [
            {
                "metric_name": "query_execution_time",
                "operator": ">",
                "value": 50
            }
        ],
        "action": "abort"
    }            
]
```

有关创建或修改查询监控规则的步骤，请参阅《Amazon Redshift 管理指南》**中的[创建查询监控规则](https://docs.amazonaws.cn/redshift/latest/mgmt/parameter-group-modify-qmr-console.html)和 [wlm\_json\_configuration 参数中的属性](https://docs.amazonaws.cn/redshift/latest/mgmt/workload-mgmt-config.html#wlm-json-config-properties)。

您可以在以下主题中找到有关查询监控规则的更多信息：
+  [预置的 Amazon Redshift 的查询监控指标](#cm-c-wlm-query-monitoring-metrics) 
+  [查询监控规则模板](#cm-c-wlm-query-monitoring-templates) 
+  [创建查询监控规则](https://docs.amazonaws.cn/redshift/latest/mgmt/parameter-group-modify-qmr-console.html) 
+  [配置工作负载管理](https://docs.amazonaws.cn/redshift/latest/mgmt/workload-mgmt-config.html) 
+  [查询监控规则的系统表和视图](#cm-c-wlm-qmr-tables-and-views) 

## 预置的 Amazon Redshift 的查询监控指标
<a name="cm-c-wlm-query-monitoring-metrics"></a>

下表描述了查询监控规则中使用的指标。(这些指标与存储在 [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md) 和 [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md) 系统表中的指标不同。) 

对于某个给定指标，将在查询级别或段级别跟踪性能阈值。有关段和步骤的更多信息，请参阅[查询计划和执行工作流程](c-query-planning.md)。

**注意**  
[WLM 超时](cm-c-defining-query-queues.md#wlm-timeout) 参数与查询监控规则不同。


| 指标 | 名称 | 描述 | 
| --- | --- | --- | 
| 查询 CPU 时间 |  query\_cpu\_time  | 查询使用的 CPU 时间（以秒为单位）。CPU time 与 Query execution time 不同。有效值为 0–999,999。 | 
| 数据块读取 |  query\_blocks\_read  | 查询读取的 1 MB 数据块的数量。有效值为 0–1,048,575。 | 
| 扫描行数 |  scan\_row\_count  | 扫描步骤中行的数量。行计数是在筛选标记为删除的行（虚影行）之前和应用用户定义的查询筛选之前发出的行的总数。<br />有效值为 0–999,999,999,999,999。 | 
| 查询执行时间 |  query\_execution\_time  | 执行查询所用的时间（以秒为单位）。执行时间不包括在队列中等待的时间。有效值为 0–86,399。 | 
| 查询队列时间 |  query\_queue\_time  | 在队列中等待所花的时间（以秒为单位）。有效值为 0–86,399。 | 
| CPU 使用率 |  query\_cpu\_usage\_percent  | 查询使用的 CPU 容量的百分比。有效值为 0–6,399。 | 
| 内存到磁盘 |  query\_temp\_blocks\_to\_disk  | 用于写入中间结果的临时磁盘空间（单位为 1 MB 数据块）。有效值为 0–319,815,679。 | 
| CPU 偏斜 |  cpu\_skew  | 任何切片的最大 CPU 使用率与所有切片的平均 CPU 使用率的比率。此指标在段级别进行定义。有效值为 0–99。 | 
| I/O 偏斜 |  io\_skew  | 任何切片的最大数据块读取 (I/O) 与所有切片的平均数据块读取的比率。此指标在段级别进行定义。有效值为 0–99。 | 
| 联接的行 |  join\_row\_count  | 联接步骤中处理的行数。有效值为 0–999,999,999,999,999。 | 
| 嵌套循环联接行数 |  nested\_loop\_join\_row\_count  | 嵌套循环联接中行的数量。有效值为 0–999,999,999,999,999。 | 
| 返回行数 |  return\_row\_count  | 查询返回的行数。 有效值为 0–999,999,999,999,999。 | 
| 段执行时间 |  segment\_execution\_time  | 执行单个段所用的时间（以秒为单位）。为避免或减少采样错误，请在规则中包括 segment\_execution\_time > 10。有效值为 0–86,388。 | 
| Spectrum 扫描行数 |  spectrum\_scan\_row\_count  | Amazon S3 中由 Amazon Redshift Spectrum 查询扫描的数据的行数。有效值为 0–999,999,999,999,999。 | 
| Spectrum 扫描大小 |  spectrum\_scan\_size\_mb  | Amazon S3 中由 Amazon Redshift Spectrum 查询扫描的数据的大小 (MB)。有效值为 0–999,999,999,999,999。 | 
| 查询优先级 |  query\_priority  | 查询的优先级。有效值为 `HIGHEST`、`HIGH`、`NORMAL`、`LOW` 和 `LOWEST`。使用大于 (>) 和小于 (<) 运算符比较 `query_priority` 时，`HIGHEST` 大于 `HIGH`，`HIGH` 大于 `NORMAL`，依此类推。 | 

**注意**  
`query_queue_time` 谓词不支持跳转操作。也就是说，在满足 `query_queue_time` 谓词时，将忽略定义了跳转的规则。
较短的段执行时间可能会导致某些指标（例如 `io_skew` 和 `query_cpu_usage_percent`）出现采样错误。为避免或减少采样错误，请在规则中包括段执行时间。`segment_execution_time > 10` 是一个好起点。

[SVL\_QUERY\_METRICS](r_SVL_QUERY_METRICS.md) 视图显示已完成查询的指标。[SVL\_QUERY\_METRICS\_SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 视图显示已完成查询的指标的最大值。使用这些视图中的值帮助确定用于定义查询监控规则的阈值。

## 查询 Amazon Redshift Serverless 的监控指标
<a name="cm-c-wlm-query-monitoring-metrics-serverless"></a>

下表描述了为 Amazon Redshift Serverless 查询监控规则中使用的指标。


| 指标 | WLM 谓词名称 | 名称 | 描述 | 
| --- | --- | --- | --- | 
| 数据块读取 |  query\_blocks\_read  |  max\_query\_blocks\_read  | 查询读取的 1 MB 数据块的数量。有效值为 0–1,048,575。 | 
| 扫描行数 |  scan\_row\_count  |  max\_scan\_row\_count  | 扫描步骤中行的数量。行计数是在筛选标记为删除的行（虚影行）之前和应用用户定义的查询筛选之前发出的行的总数。<br />有效值为 0–999,999,999,999,999。 | 
| 查询执行时间 |  query\_execution\_time  | max\_query\_execution\_time | 执行查询所用的时间（以秒为单位）。执行时间不包括在队列中等待的时间。如果查询超出设置的执行时间，Amazon Redshift Serverless 将停止查询。<br />有效值为 0–86,399。 | 
| 查询队列时间 |  query\_queue\_time  | max\_query\_queue\_time | 在队列中等待所花的时间（以秒为单位）。有效值为 0–86,399。 | 
| 内存到磁盘 |  query\_temp\_blocks\_to\_disk  |  max\_query\_temp\_blocks\_to\_disk  | 用于写入中间结果的临时磁盘空间（单位为 1 MB 数据块）。有效值为 0–319,815,679。 | 
| 联接的行 |  join\_row\_count  |  max\_join\_row\_count  | 联接步骤中处理的行数。有效值为 0–999,999,999,999,999。 | 
| 嵌套循环联接行数 |  nested\_loop\_join\_row\_count  |  max\_nested\_loop\_join\_row\_count  | 嵌套循环联接中行的数量。有效值为 0–999,999,999,999,999。 | 

**注意**  
`max_query_queue_time` 谓词不支持跳转操作。也就是说，在满足 `max_query_queue_time` 谓词时，将忽略定义了跳转的规则。
较短的段执行时间可能会导致某些指标（例如 `max_io_skew` 和 `max_query_cpu_usage_percent`）出现采样错误。

对于 Amazon Redshift Serverless，您可以使用 `wlm_json_configuration` 参数来配置查询队列和监控规则。这样，您就可以使用上面所列的指标，创建具有不同用户角色、查询组和监控规则的多个队列。有关配置无服务器查询队列的更多信息，请参阅《Amazon Redshift 管理指南》**中的 [WLM JSON 配置结构](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-workgroup-query-queues.html#serverless-wlm-json-configuration)。

## 查询监控规则模板
<a name="cm-c-wlm-query-monitoring-templates"></a>

当您使用 Amazon Redshift 控制台添加规则时，可以选择从预定义的模板中创建规则。Amazon Redshift 将创建具有一组谓词的新规则，并使用默认值填充这些谓词。默认操作是 log。您可以修改这些谓词和操作以满足您的使用案例。

下表列出了可用的模板。


| 模板名称 | Predicates | 描述 | 
| --- | --- | --- | 
| 嵌套循环联接 |  nested\_loop\_join\_row\_count > 100  | 嵌套循环联接可能表示未完成的联接谓词，这通常会产生一个非常大的返回集（笛卡尔积）。请使用一个较小的行数以及早找到潜在的失控查询。 | 
| 查询返回了大量的行 |  return\_row\_count > 1000000  | 如果您将队列指定为简单的短时间运行查询，则可包含查找返回较大行数的查询的规则。该模板使用 100 万个行的默认值。对于某些系统，您可能认为 100 万个行过大，或者在较大型系统中，100 万或更多个行可能过大。 | 
| 与大量的行联接 |  join\_row\_count > 1000000000  | 涉及异常过大行数的联接步骤可能表示需要更严格的筛选条件。该模板使用 10 亿个行的默认值。对于旨在快速简单查询的临时（一次性）队列，您可使用较小的行数。 | 
| 写入中间结果时占用大量的磁盘空间 |  query\_temp\_blocks\_to\_disk > 100000  | 如果当前正在执行的查询使用多个可用的系统 RAM，则查询执行引擎会将中间结果写入磁盘（溢出的内存）。通常，此条件是恶意查询的结果，通常也是使用大部分磁盘空间的查询。磁盘使用率的可接受阈值因集群节点类型和节点数而异。该模板使用 100000 个数据块或 100 GB 的默认值。对于小型集群，您可使用较小的数字。 | 
| I/O 偏斜高的查询运行时间长 | segment\_execution\_time > 120–和–io\_skew > 1.30  | I/O 偏斜发生在一个节点切片具有的 I/O 比率要比其他切片的比率高得多的时候。作为起点，1.30 的偏斜（平均 1.3 倍）被认为较高。高 I/O 偏斜并不总是一个问题，但在与长时间运行的查询结合时，它可能表示分配方式或排序键存在问题。 | 

## 查询监控规则的系统表和视图
<a name="cm-c-wlm-qmr-tables-and-views"></a>

当满足规则的所有谓词时，WLM 会在 [STL\_WLM\_RULE\_ACTION](r_STL_WLM_RULE_ACTION.md) 系统表中写入一行。此行包含规则所触发查询的详细信息以及所导致的操作。

此外，Amazon Redshift 还将查询指标记录到以下系统表和视图中。
+ [STV\_QUERY\_METRICS](r_STV_QUERY_METRICS.md) 表显示当前正在运行的查询的指标。
+ [STL\_QUERY\_METRICS](r_STL_QUERY_METRICS.md) 表记录已完成的查询的指标。
+ [SVL\_QUERY\_METRICS](r_SVL_QUERY_METRICS.md) 视图显示已完成查询的指标。
+ [SVL\_QUERY\_METRICS\_SUMMARY](r_SVL_QUERY_METRICS_SUMMARY.md) 视图显示已完成查询的指标的最大值。