# 并行度开到 16 反而更慢：达梦 DM9 并行参数六档实测，外加两个视图陷阱

先说结论，免得你看到一半才发现不对路：`PARALLEL_POLICY` 有三档，别当开关用。0 是禁用，1 是自动并行，2 是手动并行。0 档的时候，SQL 里写 `/*+ PARALLEL(8) */` 也进不来，执行计划照样串行。

这事我按"开关"的用法用掉好几年，一直没较真。直到这次达梦 DM9 征文，我想写点真东西，才发现自己连一个参数都没搞明白。

下面这篇是完整的实测记录。环境是单机 DM9（DM Database Server 64 V9）、CentOS 7.9、8 核、27 GB，数据是自己灌的 100 万行订单表。**所有数字只在这台机器上成立，换机器请重跑，别直接抄结论。**

![14号workbuddy开发者沙龙相关事宜沟通 (1).jpg](https://developer.qcloudimg.com/http-save/yehe-11546919/405d2ba1f00de71148a81330c01a786e.jpg)
---

## 一、一个按了五年的"开关"

社区里教开并行，最常见的一句是：

```sql
ALTER SESSION SET 'PARALLEL_POLICY' = 1;
```

翻译成人话叫"打开并行"。问题在于，只有 0 和 1 两个值的时候，它确实像开关；可它有三个值，第三个 2 一出现，事情的性质就变了。

达梦在线服务平台的《查询优化》第 22.8 节写得很清楚：

> 当 `PARALLEL_POLICY=2` 时，只能在 SQL 语句中通过 HINT PARALLEL 指定并行度，否则不并行。

三档的语义是这样：

| 值 | 模式 | 含义 | hint 是否有效 |
|---|---|---|---|
| **0** | 禁用 | 完全不并行 | 无效 |
| **1** | 自动并行 | 优化器决定是否并行，`MAX_PARALLEL_DEGREE` 是上限 | 有效，可覆盖并行度 |
| **2** | 手动并行 | 优化器不管，`MAX_PARALLEL_DEGREE` 失效，必须写 hint 才并行 | 唯一的入口 |

所以"设成 1 算不算打开并行"，答案得看你在问什么。设 1 是把"要不要并行"的决定权交给优化器，它可能给你并行，也可能觉得没必要，直接串行。设 2 是把决定权收回来给你自己，写 hint 才动。设 0 是彻底的闸刀，谁说话都不好使。

这三种语义对应三种完全不同的生产诉求。想给报表开并行，用 1；想精确控制某几条大 SQL，用 2；想按住某个会炸的库，用 0。

把三档当开关用，代价是你会以为"我开了它没生效"，然后去怪优化器。

---

## 二、2×2 对照矩阵：hint 到底进不进得来

光看文档不算数。我拿同一张表、同一条 SQL 做了四组对照，只改两个变量：策略档位、给不给 hint。

SQL 固定这一条，逐字不改：

```sql
select tenant_id, count(*) as cnt, sum(amount) as amt
  from t_ord group by tenant_id;
```

结果是这样：

| `PARALLEL_POLICY` | 不给 hint | 给 `/*+ PARALLEL(4) */` |
|---|---|---|
| 0 = 禁用 | 串行 | **串行（hint 无效）** |
| 1 = 自动（DOP=1） | 串行 | **并行** |
| 1 = 自动（DOP=8） | 并行 | 并行 |
| 2 = 手动（DOP=8） | **串行（不给就不并行）** | **并行** |

看哪一行最反直觉：第一行。我把参数压到 0，在 SQL 里老老实实写了 `/*+ PARALLEL(4) */`，执行计划出来还是串行。hint 写在那儿，一个字都没被执行器看见。

第二行也有意思。`PARALLEL_POLICY=1` 而 `MAX_PARALLEL_DEGREE=1` 的时候，不给 hint 就是串行，给了 hint 反而跑起来了。也就是说，hint 能突破 `MAX_PARALLEL_DEGREE` 的上限。

这一点达梦自己的文档是打架的。《查询优化》22.8 正文写着「若 `PARALLEL_POLICY=1`，则 SQL 语句中使用的 `PARALLEL` HINT 总是优先于 `MAX_PARALLEL_DEGREE` 参数设置」，可同一节的 hint 参数表又写取值范围是「1 ~ `MAX_PARALLEL_DEGREE`」。正文和表格互相矛盾。

实测站正文这边：hint 确实能把自动上限顶开。

顺手记一个技巧。并行到底有没有被规划进去，看执行计划的两个算子就行：`#LOCAL DISTRIBUTE`（按分组键散数据）和 `#LOCAL COLLECT`（收拢结果）。串行计划里没有这两个，出现了就说明按并行规划了。

还有一个更省事的判据：看 `explain` 的估价。1M 行 `GROUP BY`，串行估价 `[179,…]`，DOP=4 是 `[149,…]`，DOP=8 是 `[137,…]`。估价从 179 掉到 149，说明优化器确实按 4 个并行度在算代价，不是笼统地"开了个并行"。

但这里得停一下，别把话说满。**估价是申请值，不是实得值。** 官方文档写的是：实得线程数要等"执行计划准备执行之前，系统根据并行度和实际空闲的并行工作线程数来自动确定"。所以看到 `[149]`，只能说"优化器按 4 规划了计划"，不能说"真跑起来给了 4 个线程"。这两句差得很远，后面第五节会看到为什么。

---

## 三、第一个陷阱：命令成功了，参数没变

这一节是本文最值钱的部分，因为它会让人冤枉数据库。

场景很简单。我在会话里执行：

```sql
alter session set 'PARALLEL_POLICY' = 2;
```

返回"DMSQL 过程已成功完成"。然后我查 `v$dm_ini` 想确认一下：

```sql
select para_name, para_value from v$dm_ini where para_name = 'PARALLEL_POLICY';
```

结果是 0。纹丝不动。

第一反应是这命令在骗人。第二反应是去搜，能搜到一堆"达梦 alter session 不生效"的帖子。

真相是：命令没骗人。它生效了，我查错了地方。

实测在会话值改成 1、8 的状态下，几个视图给出的数字完全不同：

| 查法 | 显示 | 能反映会话值吗 |
|---|---|---|
| `SF_GET_SESSION_PARA_VALUE('X')` | 1 / 8 | 能 |
| **`V$PARAMETER.VALUE`（当前值）** | 1 / 8 | **能** |
| `V$PARAMETER.SYS_VALUE` | 0 / 1 | 不能 |
| `V$PARAMETER.FILE_VALUE` | 0 / 1 | 不能 |
| **`V$DM_INI.PARA_VALUE`** | 0 / 1 | **不能，这就是陷阱** |

原因不难理解。`V$DM_INI` 只有一列 `PARA_VALUE`，它量的是**系统级**的值，你在会话里改，它当然不动。而 `PARA_TYPE = SESSION` 这个字段标的是"这个参数允许在哪一层被改"，不是"当前值在哪一层"。

两件事长得像，含义完全不同。把前者当后者看，就会得出"命令没生效"的错误结论。

正确姿势：

```sql
-- 看当前真正生效的值
select sf_get_session_para_value('PARALLEL_POLICY') as policy,
       sf_get_session_para_value('MAX_PARALLEL_DEGREE') as dop;
```

会话级参数三个函数记一下：

```sql
SELECT  SF_GET_SESSION_PARA_VALUE('PARAM');         -- 读
CALL    SF_SET_SESSION_PARA_VALUE('PARAM', value);  -- 写
        SP_RESET_SESSION_PARA_VALUE('PARAM');       -- 还原到系统值
```

`SP_RESET_SESSION_PARA_VALUE` 是存储过程。写成 `select sp_reset_...(...)` 会直接报 `[-4015] 无效的SELECT项`，这个错我踩过一次。

还有一条验证纪律，比记住哪个视图更重要：**必须在"会话值 ≠ 系统值"的状态下查。** 如果两边一样，三个视图显示的数字全一致，你什么也证明不了，那是一次假验证。

---

## 四、六档扫描：天花板就是核数

搞清楚了怎么设、怎么验，接下来才是正经问题：并行度开多大合适。

同一会话、同一条 SQL，只改 hint 里的并行度，每档跑 3 次。为了让 hint 说话，我把 `PARALLEL_POLICY` 设成 1、`MAX_PARALLEL_DEGREE` 压到 1，这样自动并行不会插手，全靠 hint。

| 申请 DOP | 计划估价 | 3 次耗时 (ms) | 均值 |
|---|---|---|---|
| 串行 | 179 | — | 172.3 |
| 2 | **181** | 88.192 / 78.148 / 71.252 | 79.2 |
| 4 | 149 | 45.987 / 35.367 / 44.033 | 41.8 |
| 8 | 137 | 33.897 / 20.694 / 29.858 | **28.2** |
| 16 | 136 | 33.671 / 30.568 / 31.503 | 31.9 |
| 32 | 148 | 35.141 / 27.333 / 33.642 | 32.0 |

这张表里藏着三个结论，每一个都跟"并行度越大越快"的直觉反着来。

**第一，DOP=2 的估价 181，比串行的 179 还高。**

并行不是免费的。拆任务、建通道、汇总结果，都是固定开销。数据量小的时候，这笔开销能盖过并行省下的扫描时间，代价估算上就体现出来了。

但估价高不等于跑得慢。79.2 ms 对 172.3 ms，实际还是快了 2.2 倍。估价是代价估计，不是结果预测，这两件事又要分开看。

**第二，耗时在 DOP=8 见底，16 和 32 不降反升。**

28.2 ms 对 31.9 ms，申请翻倍的并行度，反而慢了大约 13%。原因不复杂，机器就 8 核。

**第三，估价的最低点在 16，耗时的最低点在 8。**

估价最低是 DOP=16 的 136，耗时最低是 DOP=8 的 28.2 ms。计划层的拐点和运行时的拐点，错开了一格。

这一格非常有意思。它说明计划里的并行度是个标记，不是事实。优化器按 16 算出来的代价最优，可运行时根本没那么多线程给你。

---

## 五、线程池的真身：10 个

顺着上面那个问题往下挖，去看线程池。

```sql
select count(*) from v$threads where thread_desc = 'Local parallel working thread';
```

10 个。名字都叫 `dm_lpq_thd`，ID 连续。

这个数字不是偶然，`PARALLEL_THRD_NUM` 的默认值就是 10（官方取值范围 1~1024）。它的类型是 IN FILE，实例级静态参数，改 `dm.ini` 重启才生效，会话里改不了。

现在把两件事对起来看。DOP=8 的时候，一条 SQL 要吃掉池子里 8 个线程，只剩 2 个余量。这时候你再申请 16 或者 32，机器不会凭空多出线程，能拿到多少算多少。所以 16 和 32 上不去。别怪并行效率，池子就这么大。

再往深说一层。达梦没有 Oracle 那种并行排队（Parallel Statement Queuing）。线程不够的时候，它的做法是**降级**。《查询优化》22.8 的原话：

> 当无法满足特定并行查询执行的线程要求时，数据库引擎就会自动减少任务个数，甚至会放弃并行查询而改为串行计划。

同一颗 SQL，每次运行拿到的实得线程数可能都不一样，取决于此刻池子里还剩几个。这句话是后面讲抖动的地基。

口径上要守住一条：`V$THREADS` 里那 10 个 `dm_lpq_thd` 是**池子规模**，不是运行时占用快照。想知道某条 SQL 真正拿到了几个线程，`V$PARALLEL_TASK` 这个视图不存在，查它会报 `[-2106]`。可以试试 `V$THRDS_POOL`、`V$LPQ_THRD_INFO`、`V$TASK_QUEUE`，这几个我在字典里命中过，但还没展开查。

---

## 六、两个容易被"加速比"盖住的代价

并行能快，这个大家都知道。下面两个代价，讲的人不多，但真出事了都在这儿。

### 代价一：耗时抖动

同一个 DOP=8，100 万行，三次耗时 33.897 / 29.858 / 20.694 ms。均值 28.2，相对抖动（极差除以均值）46.9%。

再看另一组统计：串行跑 4 次，抖动 1.58%；并行跑 8 次，抖动 58.5%，耗时区间从 28.4 到 49.8 ms。

这个差距不是测量误差。前面说过，实得线程数取决于池子当下剩几个，这就决定了并行给不了稳定的 N 倍。它给的是平均 N 倍，每一次都在赌。

还有更扎心的一组：同为 DOP=8，两轮测试的均值一个是 28.2 ms，一个是 36.7 ms，差了 30%。所以看到别人文章里一个漂亮的并行耗时数字，别急着照抄，那可能是他运气好的那一轮。

**抖动会随数据量收窄。** 1000 万行补测，DOP=8 三次是 246.276 / 230.333 / 224.477 ms，均值 233.7，相对抖动降到 9.3%。方向很明确：数据量越大，固定开销被摊得越薄，抖动越小。不过样本只有三四次，只能说方向，不能定量。

### 代价二：结果行序失稳

这个更安静，也更危险。

`GROUP BY` 的结果顺序，每次跑都不一样。

机理在计划里写着：`#LOCAL DISTRIBUTE` 按分组键把数据散到各线程，各线程各自聚合，最后 `#LOCAL COLLECT` 收拢。收拢顺序取决于谁先干完，于是行序就不固定了。

验证方法很土但有效：把参数还原，再跑一次，行序立刻恢复有序。

这件事的杀伤力在于，很多业务代码是默认"没写 ORDER BY 但顺序稳定"的。比如取结果集第一条当默认值，或者页面第一次渲染靠这个顺序。单机串行跑了五年都没事，一开并行就开始偶尔出怪数据，还复现不了。

**只要业务依赖顺序，就必须显式写 ORDER BY。** 这条要求本来就有，并行只是把那条隐性假设撕开了。

---

## 七、横向对照：达梦比 Oracle 多一档

搞清楚一个系统最好的办法，是拿一个已知的系统当坐标系。我用的是 Oracle。

Oracle 的 `PARALLEL_DEGREE_POLICY` 有四档：MANUAL（默认）、LIMITED、AUTO、ADAPTIVE。四档全都在调"自动并行的程度"，没有一档是在调"能不能并行"。

对到达梦这边：

| 达梦 `PARALLEL_POLICY` | 语义 | Oracle 对应 |
|---|---|---|
| **0** | 完全禁用，hint 也进不来 | **没有这一档** |
| 1 | 自动并行，优化器决定，hint 也认 | AUTO / LIMITED / ADAPTIVE |
| 2 | 手动并行，必须写 hint | MANUAL |

差异就落在 0 档上。Oracle Database Reference 里有一句决定性的原话：

> Automatic degree of parallelism will be enabled regardless of the value of `PARALLEL_DEGREE_POLICY` if a PARALLEL hint is used at the SQL statement level.

意思是语句级 hint 优先级最高，无视策略参数。而达梦在 `PARALLEL_POLICY=0` 的时候，hint 是完全无效的。

所以达梦这里多出一档。它把"连 hint 都拒绝"单独做成了 0 档。

这不是缺陷。恰恰相反，这是给生产库 DBA 的一个硬闸。要保证"这条 SQL 无论如何不许并行"，Oracle 得绕路，比如压 `PARALLEL_MAX_SERVERS`，副作用一大片；达梦一句 `PARALLEL_POLICY=0` 就够了，干净利落。

另一半对照是资源不足时的行为。Oracle 在 `PARALLEL_DEGREE_POLICY=AUTO` 下启用并行排队，超过 `PARALLEL_SERVERS_TARGET` 的语句排队等着，不降级。达梦没排队，线程不够就减任务、甚至退回串行。

同样是资源不够，一个让你等，一个让你变慢。哪种更好，看你是愿意排队还是愿意接受一个说不准的耗时。运维上这是两种完全不同的体验。

---

## 八、可以直接抄的验证脚本

下面这段能在 DM9 上从头跑一遍，一路验证到还原。注意几条纪律，不然结论必错。

```sql
set timing on; set linesize 200; set pagesize 1000;

-- 0) 先看参数类型，SESSION 才能 alter session set
select para_name, para_value, para_type from v$dm_ini
 where para_name in ('PARALLEL_POLICY','MAX_PARALLEL_DEGREE','PARALLEL_THRD_NUM','PARALLEL_DML');

-- 1) 造靶子：100 万行，一次成型，别用 PL/SQL 循环
drop table t_ord;
create table t_ord (id int, tenant_id int, sku_id int, amount decimal(12,2), order_ts date);
insert into t_ord
select level, mod(level,20), mod(level,5000), mod(level,9999)/3.0, date '2026-01-01' + mod(level,240)
  from dual connect by level <= 1000000;
commit;

-- 2) 基线：policy=0，连跑 3 次记第 3 次，计划里不该有 #LOCAL COLLECT
alter session set 'PARALLEL_POLICY' = 0;
alter session set 'MAX_PARALLEL_DEGREE' = 1;
explain select tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;
select tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;  -- ×3

-- 3) 开并行：policy=1 + DOP=8，计划里应出现 #LOCAL COLLECT + #LOCAL DISTRIBUTE
alter session set 'PARALLEL_POLICY' = 1;
alter session set 'MAX_PARALLEL_DEGREE' = 8;
explain select tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;
select tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;  -- ×3

-- 4) 验证生效，别用 v$dm_ini
select sf_get_session_para_value('PARALLEL_POLICY') as policy,
       sf_get_session_para_value('MAX_PARALLEL_DEGREE') as dop;

-- 5) 手动并行对照：policy=2，不给 hint 应串行，给 hint 才并行
alter session set 'PARALLEL_POLICY' = 2;
explain select tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;
explain select /*+ PARALLEL(4) */ tenant_id, count(*) as cnt, sum(amount) as amt from t_ord group by tenant_id;

-- 6) 还原（存储过程，不加 select）
sp_reset_session_para_value('PARALLEL_POLICY');
sp_reset_session_para_value('MAX_PARALLEL_DEGREE');
```

三条纪律，比脚本本身重要：

1. **一次只动一个变量。** 别在已经开了并行的会话里测 hint，那样分不清是谁的功劳。
2. **对照组 SQL 逐字相同。** 列清单、条件、分组，一个字都不能差，否则耗时不可比。
3. **每条连跑 3 次记第 3 次。** 第 1 次含硬解析开销，不能用。

清场时 `drop` 一张不存在的表会报 `[-2106] 无效的表或视图名`，那是正常表现，不是故障。

---

## 九、几个可以带走的判断

跑完这一圈，我把它总结成四句话，都是能直接用在生产上的。

**第一，先问清楚要的是哪种并行。** 自动还是手动，决定权在自己手里还是在优化器手里，这是设计决策，不是配置项。报表类想省心就用 1，几百条大 SQL 要精细控就用 2，出事要按住就用 0。

**第二，并行度的上限看池子大小，不看核数。** 这台机器 8 核、线程池 10 个，DOP=8 就有实际意义，16 和 32 纯属浪费。改机器之前先查 `PARALLEL_THRD_NUM`，它是静态参数，得改 `dm.ini` 重启。

**第三，任何单次耗时数字都别信，包括我自己上面那些。** 同一档位两轮能差 30%，三次之内抖动 46.9%。要报数字就报均值加区间，报单次是在误导人。

**第四，只要业务依赖顺序，就必须写 ORDER BY。** 并行不制造这个问题，它只是把问题从"以前碰巧没出事"变成"现在会出事"。

---

## 十、最后说几句

这篇的起因很朴素。达梦办了一场 DM9 技术征文，我想投个稿，结果发现自己对 `PARALLEL_POLICY` 的理解一直是错的。于是就装环境、造数据、一档一档跑。

跑完拿到先锋奖，算是意外。真正让我觉得值的，是那几个原本答不上来的问题现在有答案了。

参数这种事最容易凭印象。用了很多年，不等于用对了。文档写在那儿，视图查得到，机器就在手边，真要弄明白，跑一遍比想一百遍都强。

换机器、换数据量、换 SQL 形态，结论都可能变。所以这篇里所有数字都带着环境和前提，你拿去用的时候，也请把这台机器的条件一起带走。

先说结论，免得你看到一半才发现不对路：PARALLEL_POLICY 有三档，别当开关用。0 是禁用，1 是自动并行，2 是手动并行。0 档的时候，SQL 里写 /*+ PARALLEL(8) */ 也进不来，执行计划照样串行。

并行度开到 16 反而更慢：达梦 DM9 并行参数六档实测

PARALLEL_POLICY 是三档不是开关，0 档连 hint 都无效。8 核 27G 的 DM9 上扫了六档并行度：DOP=8 见底 28.2ms，16 反而 31.9ms，估价最低点还错开一格。

运维工程师

人工智能

达梦DM9并行参数PARALLEL_POLICY三档实测：0禁用、1自动、2手动，hint在0档无效。并行度8达最佳性能，16和32因8核CPU及10线程池限制反而变慢。注意V$DM_INI不显示会话值，需用SF_GET_SESSION_PARA_VALUE。并行查询存在耗时抖动和结果顺序不稳，业务需显式ORDER BY。

代码解释

数据库

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

达梦DM9并行参数PARALLEL_POLICY三档实测：0禁用、1自动、2手动，hint在0档无效。并行度8达最佳性能，16和32因8核CPU及10线程池限制反而变慢。注意V$DM_INI不显示会话值，需用SF_GET_SESSION_PARA_VALUE。并行查询存在耗时抖动和结果顺序不稳，业务需显式ORDER B...

并行度开到 16 反而更慢：达梦 DM9 并行参数六档实测-腾讯云开发者社区-腾讯云

并行度开到 16 反而更慢：达梦 DM9 并行参数六档实测

并行度开到 16 反而更慢：达梦 DM9 并行参数六档实测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐