SQL Server调优系列基础篇（并行运算总结篇二）

前言
上一篇文章我们介绍了查看查询计划的并行运行方式。
本篇我们接着分析SQL Server的并行运算。
闲言少叙，直接进入本篇的正题。
技术准备
同前几篇一样，基于SQL Server2008R2版本，利用微软的一个更简洁的案例库（Northwind）进行解析。
内容
文章开始前，我们先来回顾上一篇中介绍的并行运算，来看文章最后介绍的并行运算语句：

SELECT B1.[KEY],B1.DATA,B2.DATA
FROM BigTable B1 JOIN BigTable2 B2
ON B1.[KEY]=B2.[KEY]
WHERE B1.DATA<100




上面是详细的执行计划，从右边依次向左执行，上图中有一个地方很有意思，就是在聚集索引扫描后获取的数据，又重新了使用了一次重新分配任务的过程
（Repartition Streams），就是上图的将获取的100行数据重新分配到并行的各个线程中。
其实这里本可以直接将索引扫描出来的100行数据直接扔到嵌套循环中执行。它这里又重新分配任务的目的就是为了后面嵌套循环的并行执行，最大限度的利用硬件资源！
但这样做又带了另一个弊端就是执行完嵌套循环之后，需要将结果重新汇总，就是下面的（Gather Sreams）运算符。
我们来看看该语句如果不并行的执行计划

SELECT B1.[KEY],B1.DATA,B2.DATA
FROM BigTable B1 JOIN BigTable2 B2
ON B1.[KEY]=B2.[KEY]
WHERE B1.DATA<100
option(maxdop 1)




这才是正宗的串行执行计划。
和上面的并行执行计划相比较，你会发现SQL Server充分利用硬件资源而形成的并行计划，是不是很帅！
如果还没感觉到SQL Server并行执行计划的魅力，我们再来举个例子，看如下语句

SELECT BIG_TOP.[KEY],BIG_TOP.DATA,B2.DATA
FROM
(
SELECT TOP 100 B.[KEY],B.DATA
FROM BigTable B
ORDER BY DATA
) BIG_TOP,
BigTable2 B2
WHERE BIG_TOP.[KEY]=B2.[KEY]