DB2 dft_degree默认并行度是多少？如何设置更合理

DB2 数据库的查询并行度（degree of parallelism）由多个层面的参数共同决定，其中数据库配置参数 dft_degree 负责提供查询执行时的默认并行度。当应用程序提交的 SQL 没有通过 CURRENT DEGREE 或语句级 DEGREE 子句显式指定并行度时，优化器就会以 dft_degree 的值为基准制定执行计划。并行执行可以显著缩短大型扫描、连接和排序操作的时间，但如果这个值与实际工作负载不匹配，也会带来额外的调度开销和资源争用，因此理解它的默认行为非常重要。

从参数本质上看，dft_degree 属于数据库级别的配置，它不与单个表或索引绑定，而是影响所有未覆盖默认值的查询。它允许的取值范围包括 -1、1 以及 2 到 32767 之间的整数。下面从默认值、查看修改方法、性能影响和最佳实践几个角度展开。

dft_degree 的默认值与底层含义

dft_degree 的默认取值为 -1，这代表 ANY，也就是完全由优化器根据查询代价和系统资源自动决定并行度。优化器在生成执行计划时会参考系统的 CPU 数量、缓冲池大小、表的统计信息以及查询涉及的操作复杂度。例如一个涉及大表扫描和多表连接的复杂查询，优化器可能会分配较高的并行度；而对于一个通过主键检索单行的小查询，优化器通常会选择串行执行，因为并行启动的额外开销可能比查询本身还大。

当 dft_degree 被设置为 1 时，表示禁用数据库内并行，所有查询默认串行执行。如果设置为 2 到 32767 之间的整数，则优化器会将该值作为默认并行度，除非语句自身通过特殊寄存器或子句覆盖。需要特别注意的是，dft_degree 只负责提供默认值，它并不限制最大并行度。实际并行度还会受到数据库配置参数 max_querydegree 的上限约束，同时也要求实例级参数 intra_parallel 处于启用状态。如果 intra_parallel 被关闭，即使 dft_degree 设置得再高，也不会产生真正的并行执行计划。

并行执行的核心思路是把一个较大的查询操作拆分成多个子任务，由多个数据库代理进程同时处理，最后汇总结果。这种机制对大吞吐量的分析型查询非常有利，但并行度并不是越高越好。当并行度超过系统实际可用的 CPU 核心数时，多个线程会争抢同一批计算资源，上下文切换频繁，反而导致响应时间变长。

如何查看和修改 dft_degree

数据库管理员最常用的查看方式是使用 db2 get db cfg 命令，并配合过滤条件定位到 dft_degree 对应的配置项。不同平台可以使用不同的过滤工具，Linux 和 Unix 环境下一般使用 grep，Windows 环境可以使用 findstr。下面给出一个典型的查看命令示例。

# 查看 dft_degree 当前值
db2 get db cfg for sample | grep -i "Default query parallelism"

# 查看实例级 intra_parallel 状态
db2 get dbm cfg | grep -i "Intra-partition parallelism"

从输出中可以看到类似 Default query parallelism (DFT_DEGREE) = -1 的记录。如果需要确认优化器实际为某个查询分配的并行度，还可以在 SQL 中使用 EXPLAIN 生成执行计划，并通过 db2exfmt 工具查看算子信息中的 Degree 字段。

修改 dft_degree 同样通过数据库配置命令完成。例如希望将默认并行度固定为 4，可以执行下面的命令。修改后通常需要断开现有应用连接或重新激活数据库，新的默认值才会被后续连接所使用。

# 将默认并行度设置为固定值 4
db2 update db cfg for sample using dft_degree 4

# 恢复为优化器自动决定
db2 update db cfg for sample using dft_degree -1

修改数据库配置参数时要注意，dft_degree 的变更并不会立即终止正在运行的 SQL。对于已经建立的连接，如果没有重新连接，旧的默认值可能仍然保存在会话上下文里。因此在正式调整之后，最好通过 db2 deactivate db sample 和 db2 activate db sample 或重启应用连接池来使配置全面生效。

dft_degree 对执行计划与性能的影响

并行度设置会直接影响 DB2 优化器对表扫描、排序、哈希连接等算子的资源分配。当并行度较高时，一个大型表的扫描操作可以由多个代理进程分别读取不同的数据页，再合并结果，从而缩短总执行时间。但是这种收益只在数据量足够大、查询足够复杂的情况下才会明显。对于返回结果集很小的点查询或短事务，并行执行不仅没有意义，还会因为任务的拆分、调度和汇总带来额外延迟。

一个常见的误区是认为只要把 dft_degree 调高，系统整体性能就会提升。实际上优化器在默认值 -1 下的自动决策有时也会过于乐观。例如当表的统计信息不准确时，优化器可能错误地判断一个查询需要较高并行度，结果生成了并行计划，但并行线程之间的协调开销超过了节省的执行时间。此时可以通过降低 dft_degree 或使用 max_querydegree 限制最大并行度来纠正。

如果希望在会话级或语句级临时覆盖默认值，可以使用特殊寄存器或 DEGREE 子句。下面的 SQL 展示了两种覆盖方式，适合在不改变数据库全局配置的情况下进行测试。

-- 在会话级覆盖默认并行度，强制使用 2 个并行度
SET CURRENT DEGREE '2';

-- 在语句级使用 DEGREE 子句覆盖
SELECT * FROM large_table t1, large_table t2
WHERE t1.id = t2.id
  AND t1.status = 'A'
DEGREE 4;

通过上述方式，开发或测试人员可以快速比较不同并行度下的执行计划和实际耗时，从而为全局参数的调整提供依据。需要注意的是，CURRENT DEGREE 的设置只在当前会话有效，断开连接后即失效，不会影响数据库配置。

不同工作负载下的配置建议与监控

对于以短小事务为主的 OLTP 环境，建议将 dft_degree 设置为 1，或者保持一个较低的固定值。OLTP 查询通常只访问少量数据，串行执行能够避免并行启动开销，同时减少 CPU 调度和锁竞争。如果系统同时存在少量报表查询，可以在报表专属连接中使用 SET CURRENT DEGREE 单独提高并行度，而不是全局调高 dft_degree。

对于数据仓库或分析型 OLAP 环境，大表扫描、多表连接和分组排序操作占据主导，此时可以保持 dft_degree = -1，让优化器根据查询复杂度自动选择并行度，也可以根据服务器 CPU 核数设置一个具体值，例如 2、4 或 8。但必须同时检查 max_querydegree 的取值，确保它没有被限制为 1，否则默认并行度再高也发挥不了作用。

监控是验证配置是否合理的关键一步。管理员可以使用 db2pd -db sample -applications 查看当前活动连接和对应的代理进程数量，观察是否存在大量并行线程等待资源。还可以查询包缓存中的历史执行信息，筛选出执行时间较长或执行次数较多的语句，结合 EXPLAIN 判断其实际并行度与资源消耗是否匹配。下面是一个简单的监控查询示例。

-- 查询包缓存中平均执行时间较长的语句，辅助判断并行度是否合理
SELECT SUBSTR(STMT_TEXT,1,200) AS stmt,
       NUM_EXECUTIONS,
       TOTAL_ACT_TIME / CASE WHEN NUM_EXECUTIONS = 0 THEN 1 ELSE NUM_EXECUTIONS END AS avg_act_time
FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL, NULL, NULL, -2)) AS T
WHERE NUM_EXECUTIONS > 0
ORDER BY avg_act_time DESC
FETCH FIRST 10 ROWS ONLY;

调整 dft_degree 并不是一次性的工作，而应该结合监控指标持续迭代。如果发现某些大查询频繁出现严重的 CPU 等待或 I/O 瓶颈，可以尝试降低并行度；如果确认系统资源充足但大查询耗时仍然偏高，则可以适当提高默认并行度。每次只调整一个参数，并记录调整前后的执行时间和资源消耗，才能找到最适合当前业务负载的配置值。

DB2dft_degree默认并行度修改时间：2026-08-27 06:27:59