适用分区表的场景

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

并行查询简介

并行查询是指通过对查询计划的改造，给每一个查询计划增加更多的 CPU 和 IO 处理能力，来提高单个查询的响应时间。并行查询技术可以用于分布式执行计划的执行，也可以用于本地查询计划的执行。

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

• 大索引的创建
• 批量 DML 操作

适用并行查询的场景

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

• 充足的 IO 带宽
• 充足的内存资源以满足并行查询的需要

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

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

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

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