Aurora PostgreSQL 中并行查询的最佳实践

并行查询执行是 PostgreSQL 中的一项功能，支持将单个 SQL 查询分解为由多个后台工作进程同时处理的较小任务。PostgreSQL 可以将查询的某些部分（例如扫描、联接、聚合或排序）分配到多个 CPU 内核，而不是完全在单个后端进程中执行查询。领导进程协调此执行过程并从并行工作线程收集结果。

但是，对于大多数生产工作负载，尤其是高并发 OLTP 系统，我们建议禁用自动并行查询执行。虽然并行性可以加快对分析或报告工作负载中大型数据集的查询，但它会带来重大风险，在繁忙的生产环境中，这些风险往往大于收益。

并行执行还会带来大量开销。每个并行工作线程都是一个完整的 PostgreSQL 后端进程，它需要进程分叉（复制内存结构和初始化进程状态）和身份验证（占用 max_connections 限制中的连接槽）。每个工作线程还会消耗其自己的内存，包括用于排序和哈希操作的 work_mem，每个查询有多个工作线程，内存使用量会迅速成倍增加（例如，4 个工作线程 × 64 MB work_mem = 每个查询 256 MB）。因此，与单进程查询相比，并行查询消耗的系统资源可能要大得多。如果调整不当，它们可能会导致 CPU 饱和（多个工作线程使可用的处理能力不堪重负）、上下文切换增加（操作系统频繁在多个工作进程之间切换，增加开销并降低吞吐量）或连接耗尽（由于每个并行工作进程占用一个连接槽，因此包含 4 个工作线程的单个查询总共使用 5 个连接，1 个领导进程 + 4 个工作进程，这可能会在高并发下迅速耗尽连接池，从而防止新的客户端连接并导致应用程序故障）。在高并发工作负载下，多个查询可能会同时尝试并行执行，此时这些问题尤其严重。

PostgreSQL 根据成本估算来决定是否使用并行性。在某些情况下，如果并行计划看起来代价较低，即使在实践中并不理想，计划程序也可能会自动切换到并行计划。如果索引统计数据已过时，或者膨胀使顺序扫描看起来比索引查找更具吸引力，则可能会发生这种情况。由于这种行为，自动并行计划有时可能会导致查询性能或系统稳定性出现倒退。

要从 Aurora PostgreSQL 中的并行查询中获得最大优势，务必根据您的工作负载对这些并行查询进行测试和调优，监控系统影响，并禁用自动并行计划选择以支持查询级控制。

配置参数

PostgreSQL 使用多个参数来控制并行查询的行为和可用性。了解和调优这些参数对于实现可预测的性能至关重要：

重要注意事项

确定并行查询使用情况

查询可能会根据数据分布或统计数据转变为并行计划。例如：

SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';

此查询可能使用最近数据的索引，但切换为对历史数据进行并行顺序扫描。

您可以通过加载 auto_explain 模块来记录查询执行计划。要了解更多信息，请参阅 AWS 知识中心中的记录查询执行计划。

您可以监控 Aurora PostgreSQL 数据库实例中的查询执行计划，以检测导致当前数据库负载的执行计划，并使用 aurora_compute_plan_id 参数跟踪执行计划随时间推移的性能统计数据。要了解更多信息，请参阅监控 Aurora PostgreSQL 的查询执行计划和峰值内存

您可以监控 CloudWatch 数据库洞察，以了解与并行查询相关的等待事件。要详细了解与并行查询相关的等待事件，请浏览 IPC:并行等待事件

从 PostgreSQL 版本 18 开始，您可以使用 pg_stat_database 和 pg_stat_statements 中的新列来监控并行工作线程活动：

这些指标有助于识别计划的并行性与实际并行性之间的差异，这可能指示资源约束或配置问题。使用以下查询来监控并行执行：

对于数据库级别的并行工作线程指标：

SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();

对于查询级别的并行工作线程指标

SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;

如何控制并行性

有多种方法可以控制查询并行性，每种方法均针对不同的场景和需求而设计。

要全局禁用自动并行性，请修改参数组来设置：

max_parallel_workers_per_gather = 0;

对于用户特定的永久设置，ALTER ROLE 命令提供了一种设置参数的方法，这些参数将应用于特定用户的所有将来会话。

例如：

ALTER ROLE username SET max_parallel_workers_per_gather = 4; 可确保每次该用户连接到数据库时，其会话都将在需要时使用此并行工作线程设置。

可以使用 SET 命令来实现会话级控制，该命令可在当前数据库会话的持续时间内修改参数。当您需要在不影响其他用户或将来会话的情况下临时调整设置时，这特别有用。设置后，这些参数将保持有效，直到显式重置或会话结束。这些命令很简单：

SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;

为了实现更精细的控制，SET LOCAL 支持您修改单个事务的参数。当您需要调整事务中一组特定查询的设置时，这是理想之选，之后设置会自动恢复到以前的值。这种方法有助于防止对同一会话中的其它操作产生意外影响。

利用查询计划管理（QPM）

在 Aurora PostgreSQL 中，查询计划管理（QPM）功能旨在确保计划的适应性和稳定性，而无论数据库环境如何变化（此类变化可能导致查询计划回归）。有关更多信息，请参阅 Aurora PostgreSQL 查询计划管理概览。QPM 会对优化程序进行一定程度的控制。在 QPM 中查看已批准的计划，以确保它们与当前的并行性设置保持一致。更新或移除过时的计划，这些计划可能会强制执行不够理想的并行执行。

也可以使用 pg_hint_plan 修复计划。有关更多信息，请参阅使用 pg_hint_plan 修复计划。可以使用名为 Parallel 的提示来强制并行执行。有关更多信息，请参阅 Hints for parallel plans。

诊断并行查询行为

使用 EXPLAIN (ANALYZE, VERBOSE) 来确认查询是否使用了并行执行：

要暂时禁用并行性以进行比较：

SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
RESET max_parallel_workers_per_gather;