Azure Database for PostgreSQL 灵活服务器中的查询存储

查询存储是Azure Database for PostgreSQL灵活服务器中的一项功能，它提供了一种跟踪查询性能随时间推移的方法。 查询存储可帮助你快速找到运行时间最长且资源密集型最高的查询，从而简化了性能问题的故障排除。 查询存储自动捕获查询和运行时统计信息的历史记录，并保留它们以供查看。 它按时间切分数据，以便可以查看时间使用模式。 所有用户、数据库和查询的数据存储在Azure Database for PostgreSQL灵活服务器中命名azure_sys的数据库。

启用查询存储

查询存储无需额外付费即可使用。 这是一项选择加入功能，因此默认情况下不会在服务器上启用该功能。 可以为给定服务器上的所有数据库全局启用或禁用查询存储。 无法针对每个数据库单独启用或关闭它。

在 Azure 门户中启用查询存储

1. 登录到Azure门户并选择Azure Database for PostgreSQL灵活服务器。
2. 在菜单的“设置”部分选择“参数”。
3. 搜索 pg_qs.query_capture_mode 参数。
4. 将该值设置为 top 或 all，具体取决于你是要跟踪顶级查询，还是也要跟踪嵌套查询（即在函数或过程中执行的查询），然后选择保存。 留出最多 20 分钟以便第一批数据保存到 azure_sys 数据库中。

启用查询存储等待采样

1. 搜索 pgms_wait_sampling.query_capture_mode 参数。
2. 将值设置为 all 并保存。

查询存储中的信息

查询存储由两个存储组成：

• 用于保存查询执行统计信息的运行时统计信息存储。
• 用于保存等待统计信息的等待统计信息存储。

使用查询存储的常见方案包括：

• 确定在给定时间窗口内执行查询的次数。
• 比较时间窗口之间某个查询的平均执行时间，以查看显著的差异。
• 标识过去几个小时内运行时间最长的查询。
• 标识正在等待资源的前 N 个查询。
• 了解对特定查询的等待性质。

为尽量减少空间使用量，运行时统计信息存储中的运行时执行统计信息在一个固定的、可配置的时间范围内聚合。 可以使用视图查询这些存储中的信息。

访问查询存储信息

Azure Database for PostgreSQL灵活服务器将查询存储数据存储在azure_sys数据库中。 以下查询返回有关查询存储记录的查询的信息：

SELECT * FROM  query_store.qs_view;

此查询返回有关等待统计信息的信息：

SELECT * FROM  query_store.pgms_wait_sampling_view;

查找等待查询

等待事件类型根据相似性将不同的等待事件分组到存储桶中。 查询存储 提供等待事件类型、具体的等待事件名称以及相关查询。 将此等待信息与查询运行时统计信息相关联时，可以更深入地了解哪些内容有助于查询性能特征。

下面是有关如何使用 查询存储 中的等待统计信息深入了解工作负荷的一些示例：

配置选项

启用查询存储时，它会将数据保存在聚合窗口中。 这些窗口的长度由 pg_qs.interval_length_minutes 参数确定，该参数默认为 15 分钟。 对于每个窗口，查询存储最多存储 500 个不同的查询。 区分每个查询的唯一性的属性是 user_id （执行查询的用户的标识符）、 db_id （查询所执行的上下文中的数据库的标识符）和 query_id （唯一标识所执行的查询的整数值）。 如果不同查询数在配置的间隔内达到 500 个，则查询存储会释放 5% 记录的查询，以腾出更多空间。 首先解除分配的查询是执行次数最少的查询。

若要配置查询存储参数，请使用以下选项：

以下选项专用于等待统计信息：

使用 Azure 门户获取或设置参数的不同值。

视图和函数

可以使用 query_store 数据库的 azure_sys 架构中提供的视图和函数，查询查询存储中记录的信息并将其删除。 PostgreSQL 公共角色中的任何人都可使用这些视图来查看查询存储中的数据。 这些视图仅在 azure_sys 数据库中可用。

查询是通过查看其结构并忽略语义上不重要的任何内容（如文本、常量、别名或大小写差异）来规范化的。

如果两个查询在语义上是相同的，那么即使它们对同一引用的列和表使用不同的别名，它们也会使用相同的 query_id 进行标识。 如果两个查询之间只有在它们中使用的文本值不同，则它们也会使用相同的 query_id 进行标识。 对于使用同一 query_id 标识的查询，其 sql_query_text 将属于自查询存储启动录制活动以来首先执行的查询，或自上次放弃持久化数据以来首先执行的查询，因为执行函数 query_store.qs_reset。

查询规范化的工作原理

以下示例演示查询规范化的工作原理：

假设使用以下语句创建表：

create table tableOne (columnOne int, columnTwo int);

可以启用查询存储数据收集，一个或多个用户按此确切顺序运行以下查询：

select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";

以前的所有查询共享相同的查询 ID。 查询存储保留启用数据收集后运行的第一个查询的文本。 因此，文本为 select * from tableOne;.

以下一组查询在规范化后将与上一组查询不匹配，因为 WHERE 子句使它们在语义上不同：

select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;

但是，此最后一组中的所有查询共享相同的查询 ID。 标识它们的所有文本是批处理中第一个查询的文本： select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

最后，以下查询与上一批查询的查询 ID 不匹配。 以下列表中解释了它们不匹配的原因：

查询：

select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

不匹配的原因：列列表引用相同的两列（columnOne 和 ColumnTwo），但顺序是相反的。 顺序从上一批中的 columnOne, ColumnTwo 变为此次查询中的 ColumnTwo, columnOne。

查询：

select * from tableOne where columnTwo = 25 and columnOne = 25;

不匹配的原因：对 WHERE 子句中的表达式求值的顺序进行反向计算。 顺序从上一批中的 columnOne = ? and ColumnTwo = ? 变为此次查询中的 ColumnTwo = ? and columnOne = ?。

查询：

select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;

不匹配的原因：列的列表中的第一个表达式不再是 columnOne，但函数 abs 针对 columnOne (abs(columnOne)) 计算，这在语义上不等效。

查询：

select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;

不匹配的原因：WHERE 子句中的第一个表达式不再计算 columnOne 与某个文本的相等性，但函数 ceiling 的结果针对文本计算，这在语义上不等效。

Views

query_store.qs_view

此视图返回查询存储保存在其支持表中的所有数据。 查询存储区当前仍在内存中为活动时间窗口记录的数据，在该时间窗口结束之前不会显示出来；只有当内存中的易失性数据被收集并持久保存到磁盘上的表中后，这些数据才可见。 此视图为每个不同的数据库 (db_id)、用户 (user_id) 和查询 (query_id) 返回不同的行。

query_store.query_texts_view

此视图返回查询存储中的查询文本数据。 每个不同的 query_sql_text 都有一行。

query_store.pgms_wait_sampling_view

此视图返回查询存储中的等待事件数据。 此视图为每个不同的数据库 (db_id)、用户 (user_id)、查询 (query_id) 和事件 (event) 返回不同的行。

查询存储.查询计划视图

此视图返回已用于执行查询的查询计划。 每个不同的数据库 ID 和查询 ID 都有一行。 查询存储仅记录非实用工具查询的查询计划。

Functions

query_store.qs_reset

此函数放弃查询存储收集的所有统计信息。 它会放弃已关闭的时间窗口的统计信息，这些统计信息已保存到磁盘表上。 它还放弃当前时间窗口的统计信息，该统计信息仅存在于内存中。 只有服务器管理员角色 (azure_pg_admin) 的成员才能执行此函数。

query_store.staging_data_reset

此函数会丢弃查询存储在内存中收集的所有统计信息。 此数据尚未写入到磁盘上的表中，而这些表用于支持查询存储中所收集数据的持久保存。 只有服务器管理员角色 (azure_pg_admin) 的成员才能执行此函数。

只读模式

当 Azure Database for PostgreSQL 灵活服务器处于只读模式时，例如当 default_transaction_read_only 参数设置为 on，或者由于达到存储容量而自动启用只读模式时，查询存储不会捕获任何数据。

在具有 只读副本 的服务器上启用查询存储不会自动在任何只读副本上启用查询存储。 即使在任何只读副本上启用它，查询存储也不会记录在任何只读副本上执行的查询。 只读副本在只读模式下运行，直到将其提升为主副本。

相关内容

• 查询存储库的使用场景
• 查询存储的最佳做法
• 查询性能见解