监控 Aurora MySQL 的并行查询 - Amazon Aurora

监控 Aurora MySQL 的并行查询

如果您的 Aurora MySQL 集群使用并行查询,您可能会看到 VolumeReadIOPS 值出现增长。并行查询不使用缓冲池。因此,尽管查询速度很快,但这种优化的处理可能会导致读取操作和相关费用的增加。

除了在 Amazon RDS 控制台中查看指标中所述的 Amazon CloudWatch 指标以外,Aurora 还提供了其他全局状态变量。可以使用这些全局状态变量来帮助监视并行查询执行情况。它们可以让您深入了解为什么优化程序在给定情况下可能使用或不使用并行查询。要访问这些变量,您可以使用 SHOW GLOBAL STATUS 命令。您还可以找到在下面列出的这些变量。

并行查询会话不一定与由数据库执行的查询呈一一对应关系。例如,假设您的查询计划具有两个使用并行查询的步骤。在这种情况下,查询涉及两个并行会话,并且尝试的请求和成功请求的计数器增加 2 个。

在执行 EXPLAIN 语句以试验并行查询时,即使查询没有实际运行,也会看到指定为“未选择”的计数器增加。在生产环境中使用并行查询时,您可以检查“未选择”计数器的增加速度是否比预期速度快。此时,您可以进行调整,以便为您期望的查询运行并行查询。为此,您可以更改集群设置、查询组合、开启并行查询的数据库实例等。

将在数据库实例级别跟踪这些计数器。在连接到不同的终端节点时,您可能会看到不同的指标,因为每个数据库实例运行自己的一组并行查询。如果读取器终端节点在每个会话中连接到不同的数据库实例,您可能也会看到不同的指标。

名称 描述

Aurora_pq_bytes_returned

在并行查询期间传输到头节点的元组数据结构的字节数。除以 16,384 以与 Aurora_pq_pages_pushed_down 进行比较。

Aurora_pq_max_concurrent_requests

可以在该 Aurora 数据库实例上并发运行的最大并行查询会话数。这是一个取决于 AWS 数据库实例类的固定数字。

Aurora_pq_pages_pushed_down

并行查询避免通过网络传输到头节点的数据页面数量(每个页面具有 16 KiB 的固定大小)。

Aurora_pq_request_attempted

请求的并行查询会话数。该值可能表示每个查询具有多个会话,具体取决于 SQL 结构,如子查询和联接。

Aurora_pq_request_executed

成功运行的并行查询会话数。

Aurora_pq_request_failed

向客户端返回错误的并行查询会话数。在某些情况下,并行查询请求可能会失败,例如,由于在存储层中出现问题。在这些情况下,将使用非并行查询机制重试失败的查询部分。如果重试的查询也失败,则会向客户端返回错误并增加该计数器。

Aurora_pq_request_in_progress

当前运行的并行查询会话数。该数字适用于您连接到的特定 Aurora 数据库实例,而不适用于整个 Aurora 数据库集群。要查看数据库实例是否接近其并发限制,请将该值与 Aurora_pq_max_concurrent_requests 进行比较。

Aurora_pq_request_not_chosen

未选择并行查询以满足查询条件的次数。该值是几个其他更精细的计数器的总和。即使没有实际执行查询,EXPLAIN 语句也可能增加此计数器。

Aurora_pq_request_not_chosen_below_min_rows

由于表中的行数而未选择并行查询的次数。即使没有实际执行查询,EXPLAIN 语句也可能增加此计数器。

Aurora_pq_request_not_chosen_column_bit

由于投影列的列表中的数据类型不受支持而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_column_geometry

由于表具有 GEOMETRY 数据类型的列而使用非并行查询处理路径的并行查询请求数。有关删除此限制的 Aurora MySQL 版本的信息,请参阅 将并行查询集群升级到 Aurora MySQL 版本 3

Aurora_pq_request_not_chosen_column_lob

由于表具有 LOB 数据类型的列或具有(由于声明的长度)而在外部存储的 VARCHAR 列,因此使用非并行查询处理路径的并行查询请求数。有关删除此限制的 Aurora MySQL 版本的信息,请参阅 将并行查询集群升级到 Aurora MySQL 版本 3

Aurora_pq_request_not_chosen_column_virtual

由于表包含虚拟列而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_custom_charset

由于表具有带自定义字符集的列而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_fast_ddl

由于表当前正在被快速 DDL ALTER 语句更改而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool

由于没有足够的未缓冲表数据以值得运行并行查询而未选择并行查询的次数,即使缓冲池中的表数据少于 95%。

Aurora_pq_request_not_chosen_full_text_index

由于表具有全文索引而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_high_buffer_pool_pct

由于在缓冲池中具有较高比例的表数据(目前大于 95%)而未选择并行查询的次数。在这些情况下,优化程序确定从缓冲池中读取数据更高效。即使没有实际执行查询,EXPLAIN 语句也可能增加此计数器。

Aurora_pq_request_not_chosen_index_hint

由于查询包含索引提示而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_innodb_table_format

由于表使用不受支持的 InnoDB 行格式,因此使用非并行查询处理路径的并行查询请求数。Aurora 并行查询仅适用于 COMPACTREDUNDANTDYNAMIC 行格式。

Aurora_pq_request_not_chosen_long_trx

由于正在长时间运行的事务中启动查询而使用非并行查询处理路径的并行查询请求数。即使没有实际执行查询,EXPLAIN 语句也可能增加此计数器。

Aurora_pq_request_not_chosen_no_where_clause

由于查询不包含任何 WHERE 子句而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_range_scan

由于查询对索引使用范围扫描而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_row_length_too_long

由于所有列的总组合长度过长而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_small_table

由于表的总大小(由行数和平均行长度确定)而未选择并行查询的次数。即使没有实际执行查询,EXPLAIN 语句也可能增加此计数器。

Aurora_pq_request_not_chosen_temporary_table

由于查询引用了临时表(这些临时表使用不受支持的 MyISAMmemory 表类型)而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_tx_isolation

由于查询使用不受支持的事务隔离级别而使用非并行查询处理路径的并行查询请求数。在读取器数据库实例上,并行查询仅适用于 REPEATABLE READREAD COMMITTED 隔离级别。

Aurora_pq_request_not_chosen_update_delete_stmts

由于查询是 UPDATEDELETE 语句的一部分而使用非并行查询处理路径的并行查询请求数。

Aurora_pq_request_not_chosen_unsupported_access

由于 WHERE 子句不符合并行查询条件而使用非并行查询处理路径的并行查询请求数。如果查询不需要数据密集型扫描,或者查询是 DELETEUPDATE 语句,则会出现该结果。

Aurora_pq_request_not_chosen_unsupported_storage_type

由于 Aurora MySQL 数据库集群未使用支持的 Aurora 集群存储配置,而使用非并行查询处理路径的并行查询请求的数量。此参数适用于 Aurora MySQL 版本 3.04 及更高版本。有关更多信息,请参阅 限制

Aurora_pq_request_throttled

由于在特定 Aurora 数据库实例上已运行的最大并发并行查询数而未选择并行查询的次数。