这几天终于把《黑神话 悟空》打通关了。
从第二关开始，就全靠 “身外身法（通过吹毫毛，自动召唤一群和玩家一模一样的小猴子，并行攻击敌人）” 坐着轮椅往后打了。
OB 里也有一个和身外身法类似的好东西，叫 auto dop（自动并行执行），之前在进阶教程中简单提过两句，这里再继续多说两句作为补充。
曾经在进阶教程里写过一个并行执行的最佳实践，当时写到：
虽然只有两句话，但并不是乱写的，而是 OceanBase SQL 组的内核研发同学在支持了大量的用户性能调优需求之后给出的。
不过这个 auto dop 的最佳实践还是略显简单，我们再在这个帖子里，来给它稍微扩充一些内容，主要供使用 OceanBase 应对偏 AP 业务的用户来参考。
先介绍几个和 auto dop 的相关参数，供大家参考：
parallel_servers_target 这个参数是一个租户级系统变量，表示租户在每个节点上可申请的并行执行线程数量。默认值是 MIN CPU * px_workers_per_cpu_quota。
OB 官网文档里对这个参数含义的介绍比较模糊，说用于设置每个 Server 上的并行查询排队条件。大家可以简单理解成当这个参数指定的线程资源耗尽时，并行执行请求需要排队即可。
obclient> show variables like 'parallel_servers_target';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| parallel_servers_target | 10 |
+-------------------------+-------+
1 row in set (0.00 sec)
obclient> show parameters like 'px_workers_per_cpu_quota'\G
*************************** 1. row ***************************
zone: zone1
svr_type: observer
svr_ip: 1.2.3.4
svr_port: 22602
name: px_workers_per_cpu_quota
data_type: INT
value: 10
info: the ratio(integer) between the number of system allocated px workers vs the maximum number of threads that can be scheduled concurrently. Range: [0, 20]
section: TENANT
scope: TENANT
source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
default_value: 10
isdefault: 1
1 row in set (0.02 sec)
这个是用来限制 Auto DOP 开启时单条 SQL 的最大并行度。默认为 0，利用 cpu 和 parallel_servers_target 限制最大 dop。
例如 parallel_degree_limit = 0，parallel_servers_target = 10, min_cpu = 2, 单条 SQL 查询所读取的两个分区分布在两台 OBServer 上，则最大可用 DOP 为 min(10, 2*2) = 4。
min_cpu 可以通过 oceanbase.V$OB_UNITS 来查询：
obclient> select min_cpu from oceanbase.V$OB_UNITS;
+---------+
| min_cpu |
+---------+
| 2 |
+---------+
1 row in set (0.10 sec)
parallel_min_scan_time_threshold 的单位是 ms，当基表的扫描代价高于给参数设定的值时，就会开启并行。能够影响并行度大小。默认值设置为 1000 ms。
通过调小 parallel_min_scan_time_threshold 的值，可以降低对基表开启并行的限制，允许对评估执行时间更小基表扫描开启并行。对已经开启并行且数据量固定的表，也会使用更大的并行度进行扫描。例如：
通过 $OB_PLAN_CACHE_PLAN_STAT 中 OUTLINE_DATA 字段是否包含 PARALLEL(AUTO)。
通过 explain extended 或 dbms_xplan.display_cursor（这个系统包函数的介绍详见此帖，强烈推荐大家试用一下）。
如果是纯 AP 场景，要跑少量的复杂大查询，几乎没有需要优先处理的 DML 和小查询，那么 auto dop 的使用技巧十分简单，直接按照进阶教程里的去做即可：
set parallel_degree_limit = 32;
set parallel_degree_policy = AUTO;
auto dop 的目的是优化慢 SQL 的 rt，但是会利用更多的线程资源。这里最大的问题就是会出现少量 AP 大查询和大量 TP 小查询（小 DML）之间的资源争用。AP 慢查询如果通过开 auto dop 占用大量线程并行执行，在一定程度上，会影响分配给小查询的资源。
auto dop 不是神仙，肯定感知不到用户心中的 SQL 优先级，怎么办？那就需要人告诉数据库，SQL 的优先级是怎样的？
解决方法就是在租户内，让小查询和大查询各有各的资源组，用资源组（resource group）去进行隔离。OceanBase 在租户内，支持两种粒度的资源隔离，一种是 User 级，一种是 SQL 级。可以通过配置各个 resource group 的 max cpu，让不同 User 或者不同类型的 SQL 使用不同资源组的资源。
（这个帖子里暂且不提另一个被称作大查询队列的东西，后面有缘再更新吧）
666666
66666
很好用的功能
厉害
感谢大佬分享