人大金仓（Kingbase）在 MPP（大规模并行处理）线程设置建议

针对人大金仓（Kingbase）在 MPP（大规模并行处理）分布式架构下，对一张宽表（115个字段）进行每月 180 万数据量的查询，关于并行线程数（并行度）的建议如下：

对于每月 180 万条数据（约 1.8MB ~ 几十 MB 压缩后大小，取决于字段类型），这在现代 MPP 数据库中属于中小规模的数据量。

虽然 MPP 架构支持几十甚至上百并发，但对于这张表的查询，过高的并行度反而可能适得其反，原因如下：

数据量门槛： 180 万行数据量相对较小。如果强行分配 32 个线程，每个线程可能只处理几万行数据。此时，线程调度的开销 （Context Switching）和结果汇总的开销可能会超过实际计算数据的收益，导致"杀鸡焉用牛刀"的效果。
I/O 吞吐： 180 万行宽表（115列）的 I/O 压力通常不会达到单节点磁盘带宽的极限。通常 4-8 个线程就能充分利用磁盘读取带宽。
资源争抢： 如果你的集群还需要处理其他业务，设置过高的并行度会占用过多的 work_mem 或 CPU 资源，可能导致其他并发查询排队或变慢。

人大金仓的并行查询通常由以下参数控制，建议按需调整：

全局并行度限制： 通常设置为 CPU 核数的一半到 2 倍之间。例如服务器有 32 核，可以设置为 16。

复制代码

-- 查看当前设置
SHOW max_parallel_workers_per_gather;

-- 建议设置 (需根据服务器配置，此处为示例)
SET max_parallel_workers_per_gather = 8;

查询级 Hint（如果支持）： 如果你只想针对这张特定的大表查询指定并行度，可以使用 Hint（具体语法需参考人大金仓对应版本的手册，通常类似 PostgreSQL）：
复制代码
```
-- 示例语法，强制该查询使用 8 个并行工作进程
SELECT /*+ PARALLEL(8) */ COUNT(*) FROM your_large_table WHERE ...
```

对于这张表，除了调整并行线程数，以下优化手段对性能的提升通常比单纯调整线程数更显著：

分区表（Partitioning）： 既然数据是按月增长的（每月 180w），强烈建议按月进行范围分区 。
- 优势： 查询某个月的数据时，数据库只需扫描对应的分区文件，无需全表扫描。这比并行查询快得多。
索引优化： 确保在 WHERE 条件和 JOIN 条件上建立了合适的索引。如果查询条件包含时间字段，分区加索引是黄金组合。
统计信息： 确保表的统计信息（ANALYZE）是最新的，这样优化器才能准确判断是否使用并行查询以及使用多少个线程。

对于 180 万行的月度数据：