OceanBase 中的身外身法 —— Auto DOP（自适应并行）使用技巧分享

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 OceanBase 相关的各种技术内容。欢迎感兴趣的朋友们关注！

Part 1 背景

前一段儿时间，玩了一下火出天际的《黑神话：悟空》。

不过从第二关的虎先锋开始，游戏难度陡然而增，作为手残玩家，只能靠 “身外身法”，也就是通过吹毫毛召唤一群和玩家一模一样的小猴子来并行攻击敌人。然后就全程重度依赖这个类似于多个 Worker 并行执行玩家指令的法术，一路打到通关。

在 OceanBase 中也有一个和身外身法类似的好东西，叫做 Auto DOP（自适应并行度，DOP：Degree of Parallel），这篇文章就为大家介绍一下这个功能的使用技巧。

Part 2 划重点

先说最重要的结论性的内容：

Auto DOP 可以在一定程度上，解决需要手动设置并行度的不便。
最佳实践很简单，只有两步：
- 先根据机器性能，及可以接受的复杂查询对资源的占用比例，设置并行度上限，例如：set parallel_degree_limit = 32;
- 然后打开 Auto DOP：set parallel_degree_policy = AUTO;

Part 3 相关参数

接下来为大家介绍几个和 Auto DOP 相关的重要参数，供大家参考：

parallel_servers_target

parallel_servers_target 这个参数是一个租户级系统变量，表示租户在每个节点上可申请的并行执行线程数量。默认值是 MIN CPU * px_workers_per_cpu_quota。

OB 官网文档里对这个参数含义的介绍比较模糊，说是用于设置每个 Server 上的并行查询排队条件。大家可以简单理解成当这个参数指定的线程资源耗尽时，并行执行请求需要排队即可。

parallel_degree_limit

parallel_degree_limit 这个参数是用来限制 Auto DOP 开启时单条 SQL 的最大并行度，默认为 0。当这个参数为 0 时，系统会利用 cpu 和 parallel_servers_target 来限制最大 dop。

例如 parallel_degree_limit = 0 时：

parallel_servers_target = 10
min_cpu = 2
单条 SQL 查询所读取的两个分区分布在 2 台 OBServer 上

则最大可用 DOP 为 min(10, 2 * 2) = 4。

min_cpu 可以通过 oceanbase.V$OB_UNITS 来查询：

parallel_min_scan_time_threshold

parallel_min_scan_time_threshold 的单位是 ms，当基表的扫描代价高于给参数设定的值时，就会开启并行。能够影响并行度大小。默认值设置为 1000 ms。

通过调小 parallel_min_scan_time_threshold 的值，可以降低对基表开启并行的限制，允许对评估执行时间更小基表扫描开启并行。对已经开启并行且数据量固定的表，也会使用更大的并行度进行扫描。例如：

Part 4 查询是否使用了 Auto DOP

方法一

通过 $OB_PLAN_CACHE_PLAN_STAT 中 OUTLINE_DATA 字段是否包含 PARALLEL(AUTO)。

方法二

通过 explain extended 或 dbms_xplan.display_cursor（这个系统包函数的介绍详见 OceanBase 社区论坛中的这个帖子，强烈推荐大家试用一下）。

Part 5 不同场景的使用建议

AP 场景

如果是纯 AP 场景，要跑少量的复杂大查询，几乎没有需要优先处理的 DML 和小查询，那么 Auto DOP 的使用技巧十分简单：

先根据机器性能，及可以接受的复杂查询对资源的占用比例，设置并行度上限，例如：set parallel_degree_limit = 32;
打开 Auto DOP：set parallel_degree_policy = AUTO;

AP TP 混布场景

Auto DOP 的目的是优化慢 SQL 的 RT（run time），但是会利用更多的线程资源。这里最大的问题就是会出现少量 AP 大查询和大量 TP 小查询（小 DML）之间的资源争用。AP 慢查询如果通过开 Auto DOP 占用大量线程并行执行，在一定程度上，会影响分配给小查询的资源。

Auto DOP 不是神仙，肯定感知不到用户心中的 SQL 优先级，怎么办？那就需要人告诉数据库，SQL 的优先级是怎样的？

解决方法就是在租户内，让小查询和大查询各有各的资源组，用资源组（resource group）去进行隔离（这里暂且不提另一个被称作大查询队列的东西，在公众号后续的运维技巧内容里会为大家进行介绍）。

OceanBase 在租户内，支持两种粒度的资源隔离，一种是 User 级，一种是 SQL 级。可以通过配置各个 resource group 的 max cpu，让不同 User 或者不同类型的 SQL 使用不同资源组的资源。

Part 6 总结

如果需要精细地对 Auto DOP 的并行度进行控制，就需要对控制并行度下限（启用并行执行的起步价 parallel_min_scan_time_threshold）和上限（节点中用于并行执行的线程数上限 parallel_servers_target，以及单条 SQL 中的线程数上限 parallel_degree_limit），根据机器配置和实际需求进行调整。如果不设置，默认就会把尽量多的资源给并行执行去使用（对于纯 AP 场景也许就是最优解）。
在同一个租户内，同时存在 AP TP 业务的场景下，可以考虑把 Auto DOP 和资源组绑到一起去用。

️ #老纪的技术唠嗑局不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星吧！你的每一个Star，都是我们努力的动力～

https://github.com/oceanbase/oceanbase