怎么在Navicat中分析PostgreSQL的并行查询计划？

Navicat里点“解释”看不到Parallel节点，是因为PostgreSQL 10+虽支持并行查询但默认关闭，需确认服务端配置（如max_parallel_workers_per_gather>0）、查询满足并行条件（无volatile函数、非写操作），并手动使用EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)语句配合勾选Include analyze/buffers才能正确渲染Parallel Seq Scan等节点。

Navicat里点“解释”看不到Parallel节点？先确认PostgreSQL版本和配置

postgresql 10+ 才支持并行查询，但默认是关闭的。navicat 能否显示 parallel seq scan、parallel index scan 这类节点，取决于服务端是否启用并行能力，不是客户端能决定的。

常见错误现象：EXPLAIN 输出里完全没有 Parallel 字样，或 Navicat 执行计划窗口只显示普通 Seq Scan —— 这说明服务端压根没走并行路径。

• 检查 max_parallel_workers_per_gather 是否 > 0（默认为 2，但某些部署被设为 0）
• 确认 parallel_setup_cost 和 parallel_tuple_cost 没被调得过高（比如设成 1000），导致优化器直接放弃并行
• 确保查询本身适合并行：不能含 volatile 函数（如 now()、random()）、不能是写操作、不能在事务中带 FOR UPDATE
• Navicat 15 及更早版本对 PostgreSQL 14+ 的 Parallel Append 或 Gather Merge 节点渲染不全，建议升级到 Navicat 17

在Navicat中正确触发并行执行计划的实操步骤

Navicat 默认用的是 EXPLAIN (FORMAT TEXT)，它会省略很多并行细节。要看到真实并行行为，必须手动构造语句并控制输出格式。

• 在查询编辑器中写完整语句：EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT ... —— FORMAT JSON 是关键，Navicat 能解析 JSON 并展开 Parallel 分支；TEXT 格式会把并行子节点折叠成一行
• 务必勾选界面右上角的 Include analyze 和 Include buffers，否则看不到实际 worker 数量、shared hit/reads 等核心指标
• 避免在语句末尾加 ;（PostgreSQL 的 EXPLAIN ANALYZE 不接受分号结尾，否则 Navicat 会静默失败）
• 如果目标表小于 min_parallel_table_scan_size（默认 8MB），即使配置全开也不会触发并行，可临时设为 SET min_parallel_table_scan_size = '1MB'; 测试

看懂并行计划里最关键的三处字段

Navicat 渲染的 JSON 格式执行计划是树状结构，别从顶层往下读。直接定位这三个位置：

• Workers Launched：出现在 Gather 或 Gather Merge 节点下，数字就是实际启动的 worker 数（如 "Workers Launched": 2）。为 0 就等于没并行
• Actual Total Time 下方的 Workers 数组：每个 worker 的耗时、rows、shared_blks_read 等，对比主进程看负载是否均衡
• Plans 字段下的子节点：真正的并行扫描节点（如 Parallel Seq Scan）一定嵌套在 Gather 的 Plans 里，而不是平级出现

注意：如果 Workers Launched 是 2，但 Plans 里只有一个子节点，说明并行被降级了——大概率是内存不足（work_mem 太小）或统计信息过期（ANALYZE table_name 没跑）。

为什么用EXPLAIN ANALYZE测并行反而比单线程还慢？

并行不是万能加速器。Navicat 里点 Explain Analyze 后发现总耗时暴涨，往往是因为协调开销压倒收益。

• 小结果集（rows < 10000）几乎从不受益于并行，Gather 节点本身的同步成本就可能超过扫描节省的时间
• 高并发场景下，多个并行查询争抢 max_parallel_workers 全局槽位，导致排队等待，EXPLAIN ANALYZE 显示的 Planning Time 会异常升高
• 若查询涉及大量 shared_blks_read，而磁盘是 HDD 或网络存储，多 worker 同时读容易引发 I/O 争抢，实际吞吐反而下降
• Navicat 不会自动加 SET statement_timeout = '30s'，一旦并行卡住（如等锁、等 buffer），你得手动中断，否则窗口一直转圈

真正需要关注的不是“有没有并行”，而是“并行是否带来净收益”。用 EXPLAIN (ANALYZE, BUFFERS) 对比开启/关闭并行（SET max_parallel_workers_per_gather = 0）的 Actual Total Time 和 Shared Hit Ratio，才说得清。