查询存储的使用方案 - Azure Database for PostgreSQL 灵活服务器
适用于：
Azure Database for PostgreSQL 灵活服务器
可以在各种方案中使用查询存储，在这些方案中，跟踪和维护可预测的工作负载性能至关重要。 请开考虑以下示例：
- 识别并优化消耗高的查询。
- 执行 A/B 测试。
- 识别并改进临时工作负载。
识别并优化消耗高的查询
识别长时间运行的查询
在服务器的 azure_sys 数据库上使用查询存储视图来快速确定运行时间最长的查询。 这些查询往往占用最多的资源。 优化运行时间最长的查询可以通过释放系统上运行的其他查询所用的资源来提高性能。
使用性能增量定位查询
查询存储将性能数据切分为多个时间窗口，使你可以跟踪查询随时间变化的性能。 这有助于精确地确定哪些查询会增加花费的总时间。 因此，你可以对工作负载进行限定范围的故障排除。
优化成本高昂的查询
发现查询的性能不佳时，采取的操作取决于问题的性质。 此类操作可能包括：
- 确保查询使用的基础表的统计信息是最新的。
- 考虑重新编写消耗大量资源的查询。 例如，利用查询参数化并减少临时 SQL 的使用。 在读取数据时实现最佳逻辑，例如在数据库端（而非在应用程序端）应用数据筛选。
执行 A/B 测试
使用查询存储比较计划引入的应用程序更改实施前后或者迁移前后的工作负载性能。 使用查询存储评估更改对工作负载性能的影响的示例方案：
- 在 PostgreSQL 的主要版本之间迁移。
- 推出新版本的应用程序。
- 修改向服务器授予的资源量。
- 更改影响服务器行为的任何服务器参数。
- 在消耗大量资源的查询引用的表上创建缺失的索引。
- 从 Azure Database for PostgreSQL 单一服务器迁移到 Azure Database for PostgreSQL 灵活服务器。
在任何一个这样的方案中，应用以下工作流：
- 在计划的更改之前使用查询存储运行工作负载，以生成性能基线。
- 在受控时刻应用所需的更改。
- 在足够的时间内继续运行工作负载，以便清楚地了解更改后的系统性能。
- 比较更改前后的结果。
- 决定是保留更改还是回退。
识别并改进临时工作负载
某些工作负载没有可通过优化来提高应用程序整体性能的主查询。 它们通常具有相对大量的唯一查询，其中每一个都占用部分系统资源。 每个唯一查询的执行频率都不高，因此它们各自的运行时消耗并不重要。 另一方面，假设应用程序一直在生成新查询，则系统资源的很大一部分会花费在查询编译上，这不是最佳选择。 通常情况下，如果你的应用程序生成查询（而不是使用存储过程或参数化查询），或者它依赖于默认生成查询的对象关系映射框架，则会发生这种情况。
如果你能控制应用程序代码，则可以考虑重写数据访问层以使用存储过程或参数化查询。 但是，通过强制对整个数据库（所有查询）或具有相同查询哈希的单个查询模板进行查询参数化，可以在不更改应用程序的情况下改善这种情况。