DB2数据库的并行能力可以划分为两类：跨数据库分区的inter-partition parallelism和单个分区内部的intra-partition parallelism。前者通常依赖DPF或purescale环境，将数据分布到多个逻辑节点上并行处理；后者则由INTRA_PARALLEL参数控制，决定一条SQL语句能否在同一个数据库分区内使用多个CPU核心协同完成扫描、连接、排序和聚合等操作。对于大多数使用单分区数据库的用户来说，INTRA_PARALLEL是提升分析型SQL吞吐量的关键开关。
多核服务器上的CPU资源能否被一条复杂查询充分利用，往往取决于这个参数。因为DB2默认关闭查询内并行，避免高并发短查询场景下产生不必要的线程调度和通信成本。但在报表、数据仓库或批量ETL场景中，如果不打开该参数，一张几千万行的表即使执行全表扫描，通常也只会占用一个执行代理线程，导致响应时间远高于硬件能力。
一、intra_parallel 参数的基本作用
在DB2的并行体系结构中，INTRA_PARALLEL是一个数据库级配置参数，默认值为NO。它主要用于控制查询内并行（intra-partition parallelism），也就是单个SQL语句在一个数据库分区范围内能否被拆分为多个并行执行单元。与之对应的是查询间并行，即多个SQL语句各自使用独立代理线程，这种能力通常在数据库管理器中默认存在。
当INTRA_PARALLEL被设置为YES后，DB2优化器在生成访问计划时会评估查询成本，如果判断并行执行有利，就会把扫描、连接、分组、排序等操作分解为多个子任务。这些子任务会由不同的执行代理（agent）线程同时处理，并在需要交换数据的算子之间通过共享内存或队列进行通信。例如一个大表与一个小表的哈希连接，可以启动多个代理分别扫描大表的不同数据块，再与内存中的小表哈希表做匹配。
需要特别说明的是，该参数并不是简单的全局开关。即使设置为YES，并行的实际程度仍然受到统计信息、数据库配置以及SQL复杂度的影响。如果统计信息不准确，优化器可能给出顺序执行计划；如果没有足够的CPU或缓冲池资源，并行执行也可能因为等待I/O而达不到预期加速。因此，开启该参数后还需要通过合理的参数组合和访问计划分析来验证真实效果。
二、参数配置与相关并行度限制
要查看当前数据库的INTRA_PARALLEL配置，可以在连接数据库后执行以下命令。需要注意的是，某些参数在数据库有活动连接时更新可能失败，建议在无业务窗口进行操作。
db2 connect to sample db2 get db cfg for sample | grep -i INTRA_PARALLEL
如果输出中INTRA_PARALLEL的值为NO，可以通过如下命令将其修改为YES。修改后需要断开所有连接并重新激活数据库，部分环境可能需要重启数据库实例才能完全生效。
db2 connect to sample db2 update db cfg for sample using INTRA_PARALLEL YES db2 terminate db2 connect to sample
与INTRA_PARALLEL关系密切的另一个参数是MAX_QUERYDEGREE，它用于限制单条SQL语句的最大并行度。默认值通常是ANY，表示优化器可以自行决定；也可以设置为一个具体的正整数，例如4，表示最多使用4个执行单元。在CPU数量较多的服务器上，如果担心并行查询过度占用资源，影响其他在线交易，建议将该值控制在实际核心数的四分之一到一半。另一个参数DFT_QUERYDEGREE则可以指定当优化器无法确定时的默认并行度，但一般保持默认即可。
三、通过访问计划验证并行执行
开启参数只是第一步，真正需要确认的是优化器是否为目标SQL选择了并行计划。DB2提供了db2exfmt工具，能够将解释表中的访问计划进行格式化输出。以下示例演示如何对一条统计查询生成访问计划：
db2 connect to sample db2 set current explain mode explain db2 "select count(*) from sales_fact where order_date >= '2024-01-01'" db2 set current explain mode no db2exfmt -d sample -g TIC -w -1 -n % -s % -# 0 -o exfmt.out
查看生成的exfmt.out文件时，如果出现多个相同的表扫描节点或带有并行标记的连接、排序算子，通常说明查询已经使用了intra-partition parallelism。相反，如果整个计划中只有一个顺序扫描节点，或者优化器明确显示并行度为1，则需要检查参数是否真正生效、统计信息是否过旧，以及是否有其他资源限制。
除了访问计划，还可以使用db2pd -db sample -edus命令观察执行期间的EDU数量。当执行一条大型并行查询时，通常可以看到多个db2ag代理线程同时处于活动状态，而单线程查询往往只有一个主要代理。这种方法适合在无法直接查看访问计划时快速判断并行工作情况。
四、适用场景与调优建议
并不是所有数据库都适合开启INTRA_PARALLEL。对于以大量短小事务和索引点查为主的OLTP系统，开启该参数可能会带来负面影响。原因是并行查询需要额外的代理线程创建、任务分配和数据交换，这些开销在毫秒级别的查询中可能比收益更大。尤其是在CPU资源本身已经接近饱和时，并行查询会加剧线程争用，导致整体吞吐量下降。
相反，数据仓库、报表系统、批量加工以及包含大表扫描、多表连接、聚合排序的复杂SQL，通常能从这个参数中获得明显收益。建议在测试环境使用真实业务负载进行对比：先关闭参数压测，再开启参数压测，对比平均响应时间、CPU利用率和关键SQL的执行时长。如果发现个别查询因为并行度太高反而变慢，可以通过调整MAX_QUERYDEGREE来限制资源消耗。
最后要注意，并行查询对缓冲池、I/O通道和排序堆内存的消耗都会相应增加。开启INTRA_PARALLEL后，建议同步关注SHEAPTHRES和缓冲池命中率等指标，必要时扩大排序堆内存或增加缓冲池大小，避免因为内存不足导致并行查询频繁溢出到临时表空间。
DB2intra_parallel查询并行度修改时间：2026-08-30 00:12:15