对于Sharing Nothing的分布式系统来说，由于一个关系数据表的数据会以分区的方式存放在系统里面的各个节点上，对于跨分区的数据查询请求，必然会要求执行计划能够对多个节点的数据进行操作，天然的具有分布式执行计划生成和执行能力的需求。与之相对应的，并行查询是指通过对查询计划的改造，给每一个查询计划增加更多的CPU和IO处理能力，来提高单个查询的响应时间。并行查询技术可以用于分布式执行计划的执行，也可以用于本地查询计划的执行。本章主要讨论关于分布式计划生成和并行查询在OceanBase中的调优。

当单个查询所要访问的数据不在一个节点上的时候，需要通过数据重分布的方式，将相关的数据分布到同样的计算节点进行计算，以每一次的数据重分布节点为上下界，OceanBase的执行计划被划分为一个个的Job，而每一个Job可以被切分为并行度个Task进行并发的执行以提高执行效率。典型的来说，当并行度被提高时，查询的响应时间会缩短，更多的CPU、IO和内存资源会被用于查询的执行。对于大数据量查询处理的决策支持系统或者数据仓库型应用来说，查询时间提升会尤为明显。整体来说，并行查询的总体思路和分布式执行计划有相似之处，将执行计划分解之后，不同于串行执行将整个计划由单个执行线程执行，将执行计划的每个部分分由多个执行线程执行，通过一定的调度的方式，实现执行计划的Job与Job之间的并发执行和Job内部的并发执行。在在线交易（OLTP）场景下，也可以适用于批量更新操作，创建索引，维护索引等等操作。

一般的，并行查询可以提高以下场景处理性能：

• 查询中需要处理大数据量表的连接，扫描，分区索引表的扫描

• 大索引的创建

• 批量DML操作

建议使用分区表的场景和方式

如果关系表比较小，则不必要进行分区，如果关系表比较大，则需要根据上层业务需求，审慎选择分区键，以保证大多数查询能够使用分区键进行分区裁剪以减少数据访问量。同时，对于有关联性的表，建议采用关联键作为分区键，采用相同分区方式，使用table group的方式将相同分区配置在同样的节点上，以减少跨节点的数据交互。OceanBase的优化器会自动根据查询和数据的物理分布生成分布式执行计划。

建议使用并行查询的场景

并行查询对于以下情况有显著效果

• 充足的IO带宽

• 系统CPU负载较低

• 充足的内存资源以满足并行查询的需要如果系统没有充足的资源进行额外的并行处理，使用并行查询或者提高并行度并不能提高执行性能。相反，在系统过载的情况下，操作系统被迫进行更多的调度，上下文切换或者页面交换，可能会导致性能的进一步下降。通常在D(ecision)S(upport)S(ystem)系统，大量分区需要被访问和数据仓库环境下，并行执行能够提升执行响应时间。OLTP系统通常在批量DML操作或者进行schema维护操作时能够受益，例如进行index的创建等。对于简单的DML操作或者分区内查询以及涉及分区数比较小的查询来说，使用并行查询并不能很明显的提高查询响应时间。

还有需要注意的是，当想要通过并行查询得到最佳的性能表现时，系统的每一个组成部分需要共同的进行配置。因为任何一个部分的性能表现瓶颈都会成为制约整个系统表现的单点。

可以使用并行查询的操作

下述各种查询操作都可以使用并行查询:

• 各种Access methods全表扫描（包括分区间并行和分区内并行扫描），索引表扫描

• 各种表连接操作包括nested loop join， merge join和hash join

• 其他一些SQL操作包括一些聚合操作，例如group by， distinct，sum等，limit算子的下压等等