高级：查询执行期间的并行

SQL Anywhere 支持两种不同类型的并行查询。查询间并行和查询内并行。查询间并行是指在多个单独的 CPU 上同时执行多个不同请求。每个请求（任务）都在单个线程上运行，并在单个处理器上执行。

查询内并行是指多个 CPU 同时处理一个请求，这样便可以在多处理器硬件上并行计算查询的各个部分。这些部分的处理由交换算法进行。

若同时执行的查询数目通常少于可用处理器数目，则在这样的负载情况下，采用查询内并行会带来帮助。最大并行度由 max_query_tasks 选项的设置控制。

仅当预期并行操作可提高性能时，优化程序才会估算并行操作的额外开销（额外复制行的开销以及协调工作的额外开销）并选择并行计划。

查询内并行机制不用于优先级选项设置为后台的连接。

如果当前正在处理请求的服务器线程数（服务器属性 ActiveReq），最近超出了授权该数据库服务器使用的计算机上的 CPU 内核的数量，则不使用查询内并行机制。确切的时间段由服务器决定，通常为几秒钟。

并行执行

某个查询是否可以利用并行执行，这取决于多种因素：

优化时系统中的可用资源（例如，内存、高速缓存中的数据量等）
计算机上逻辑处理器的数目
用于数据库存储的磁盘设备的数目，与处理器的相对速度以及计算机的 I/O 体系结构。
请求所需的特定代数运算符。SQL Anywhere 支持五种可以并行方式执行的代数运算符：
- 并行顺序扫描（表扫描）
- 并行索引扫描
- 并行散列连接以及散列半连接和反半连接的并行版本
- 并行嵌套循环连接以及嵌套循环半连接和反半连接的并行版本
- 并行散列过滤
- 并行散列分组依据

使用了不支持的运算符的查询仍然能够并行执行，但是就像在 Interactive SQL 中看到的一样，计划中支持的运算符必须在不支持的运算符之下出现。在一个查询中，如果大部分不支持的运算符可在顶部附近出现，则该查询更有可能使用并行机制。例如，虽然排序运算符不能并行，但是如果将排序运算符放在计划的顶部且所有的并行运算符都在其之下，则在最外层块中使用了 ORDER BY 的查询就可以并行。相比之下，在派生表中使用了 TOP n 和 ORDER BY 的查询使用并行机制的可能性则比较小，因为排序必须在计划顶部之外的地方出现。

缺省情况下，SQL Anywhere 将假定任何 dbspace 均驻留在具有单个盘片的磁盘子系统上。尽管在此类环境下并行执行查询会有很多优点，但是，除非表数据全部驻留在高速缓存中，否则优化程序用于单个设备的 I/O 开销模型使得优化程序很难选择并行表或索引扫描。但若使用 ALTER DATABASE CALIBRATE PARALLEL READ 语句校准磁盘子系统，优化程序即可通过更准确地估算开销来判断并行执行的好处。当磁盘子系统具有多个盘片时，优化程序很可能选择具有并行机制的执行计划。

当查询内并行用于访问计划时，该计划将包含一个交换运算符，其作用是合并（联合）每个子树的并行计算的结果。交换运算符下的子树的数目就是并行度。每个子树或访问计划组件都是一个数据库服务器任务。数据库服务器内核会基于执行线程（或纤程）的可用性以对待单个 SQL 请求的方式调度这些要执行的任务。这种体系结构意味着任何访问计划的并行计算主要是自行调优的，因为并行执行任务的工作在服务器内核允许的线程（纤程）上进行调度，并平均地执行计划组件任务。

另请参见

查询中的并行机制

使用DocCommentXchange讨论此页。