INTRA_PARALLEL是DB2中控制分区内部并行（intra-partition parallelism）的核心数据库配置参数。它决定了一条SQL语句能否被数据库管理器拆分成多个可并行运行的片段，交由不同的CPU核心同时处理。对于数据仓库类的大查询，合理启用并行度能带来数倍的性能提升；而对于以短小事务为主的OLTP系统，盲目开启反而会造成资源争抢和响应时间抖动。本文将从参数本身、配套参数、内存影响和监控验证几个层面，完整梳理INTRA_PARALLEL的设置思路。
INTRA_PARALLEL参数的取值与含义
INTRA_PARALLEL是一个数据库级别的配置参数，它有三个可选值：NO、YES和ANY。设为NO时，数据库管理器不会对单条语句做并行拆分，每个查询只使用一个代理进程执行，这也是绝大多数纯OLTP系统的推荐设置。设为YES时，启用分区内部并行，查询优化器会在成本模型认为划算的情况下，把扫描、排序、连接等操作切分成多个并行的子代理（subagent）来执行。
ANY是一个比较特殊的取值，它允许并行，但具体是否使用由优化器根据当时的系统负载和语句特征自行判断，适用于负载波动较大的混合型系统。需要注意的是，从DB2 9.7开始，INTRA_PARALLEL的默认值在多CPU环境下有所调整，所以在升级或新建数据库后，务必用命令确认当前生效值，而不是想当然地认为它保持默认关闭。
-- 查看当前INTRA_PARALLEL设置 db2 get db cfg for SAMPLE | grep -i intra -- 修改为启用并行 db2 update db cfg for SAMPLE using INTRA_PARALLEL YES -- 生效需要重启数据库（部分版本支持自动生效，建议重启确认） db2stop force db2start
修改该参数后建议观察一段时间，因为它影响的是优化器的决策空间，同样的SQL在参数变更前后可能生成完全不同的访问计划，这也是排查性能突变时需要优先检查的配置项之一。
与DFT_DEGREE的配合关系
INTRA_PARALLEL只是打开了并行的大门，真正控制并行程度的是Degree of Parallelism，即并行度数值。DB2中这个数值由多个层级共同决定，优先级从高到低依次是：语句级别的SET CURRENT DEGREE、绑定包时的DEGREE选项、数据库配置参数DFT_DEGREE。也就是说，即使INTRA_PARALLEL设为YES，如果DFT_DEGREE保持为1，普通应用发起的查询依然不会并行执行。
DFT_DEGREE可以设为具体数字（如4、8），也可以设为ANY，表示由优化器根据表分区数和CPU数量自动估算并行度。实践中的一个常见做法是：数据库级设置一个适中的默认值，比如4，然后针对个别大报表查询在会话级显式提高并行度，这样既避免全局并行过度，又能让关键查询跑得够快。
-- 会话级别设置并行度为8 SET CURRENT DEGREE = 8; -- 查看当前会话并行度 VALUES CURRENT DEGREE; -- 恢复默认 SET CURRENT DEGREE = '1';
另外要注意并行度并非越大越好。并行度提升后，每个子代理都需要独立的排序堆和私有内存，数值过大容易触发内存不足或者导致系统其他负载被饿死。一般建议并行度不超过逻辑CPU核数的一半，混合负载系统则从更小的值起步逐步调优。
并行带来的内存放大与风险评估
启用分区内并行最容易被忽视的代价是内存消耗的成倍增长。DB2的排序、哈希连接等操作依赖SHEAPTHRES和SORTHEAP相关的内存区域。当一条语句被拆成N个并行子代理时，每个子代理都可能各自执行排序，理论上排序内存的占用会接近单代理模式的N倍。如果SHEAPTHRES设置不足，会出现排序溢出到临时表空间的情况，表现为磁盘活动激增、查询反而变慢。
因此在开启INTRA_PARALLEL之前，应该先评估当前系统的空闲内存和共享堆阈值。可以借助快照监控中的排序溢出计数器来判断基线状态，如果单代理模式下就偶尔溢出，那么并行化之前必须先扩容SORTHEAP或SHEAPTHRES，否则只是把问题放大了N倍。
-- 查看排序堆相关配置
db2 get db cfg for SAMPLE | grep -i -E "sortheap|sheapthres"
-- 通过监控表函数查看排序溢出情况
SELECT SUBSTR(STMT_TEXT,1,60) AS STMT,
TOTAL_SORTS,
SORT_OVERFLOWS
FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL,NULL,NULL,-1))
WHERE SORT_OVERFLOWS > 0
ORDER BY SORT_OVERFLOWS DESC;除了内存，锁的行为也会变化。并行子代理在访问数据时可能以不同模式获取锁，某些场景下会增加死锁或锁等待的概率，这在高并发写入系统中尤其需要留意。
如何验证并行是否真正生效
参数改完只是第一步，确认并行执行真的发生了才算闭环。最直接的方法是查看访问计划：用db2expln或db2exfmt生成执行计划，在计划输出的头部信息中会显示Degree of Parallelism，如果显示为1，说明语句没有被并行化，需要检查INTRA_PARALLEL、DFT_DEGREE以及语句本身是否满足并行条件，比如某些包含外部标量函数的语句无法并行。
-- 导出指定语句的执行计划
db2expln -d SAMPLE -f query.sql -g -o plan.out
-- 查看活动连接的实时并行子代理数
SELECT APPLICATION_HANDLE,
NUM_EXECUTABLES
FROM TABLE(MON_GET_CONNECTION(NULL,-1))
WHERE NUM_EXECUTABLES > 1;NUM_EXECUTABLES大于1通常意味着该连接正在使用多个子代理执行语句。结合MON_GET_WORKLOAD等监控视图，还可以观察并行查询对CPU和内存的实际消耗，为后续微调提供数据支撑。
总结来说，INTRA_PARALLEL的设置没有放之四海而皆准的答案：数据仓库场景可以放心开启并配合较高并行度，纯交易系统建议保持NO，混合负载则推荐ANY加会话级精细化控制，并在每次调整后用执行计划和监控数据验证效果，形成配置、观测、迭代的完整闭环。
DB2INTRA_PARALLEL并行度修改时间：2026-09-13 01:26:43