oracle数据库菜鸟教程 sqlserver日志查看 _云知道

在《深入解析SQL Server并行执行原理及实践（上）》谈完并行执行的原理，咱们再来谈谈优化，到底并行执行能给我们带来哪些好处，我们又应该注意什么呢，下面展开。
Amdahl’s Law
再谈并行优化前我想有必要谈谈阿姆达尔定律，可惜老爷子去年已经驾鹤先去了。

其中 P：可以并行的百分比
N：算法并行计算使用的“CPU”
这里我们举个简单的例子，我们来做一份大餐，如图1-1所示：

图1-1
土豆泥，荷兰豆，鸡排还有整体组合各需十分钟。在这里前三个食材是可以共同执行的，也就是说4个步骤中3步可并行 P=3/4，其中3个食材可同时加工N=3，则根据公式S(N)=1/(1-0 。75)+0 。75/3 =2这个操作整体相比完全串行可提升200%即做这个大餐的时间由40分钟，缩短到20分钟。
这里实际引申出一个事实，整体的操作时间和整体事务中串行的比例多少有很大关联，这个引申到我们的并行调优中，并行可以改进查询，但受串行部分影响也是很大的，同时也告之我们没有必要过度串行优化，还是做大餐，即便并行可做的越来越多，但改进的效果却越发不明显，过度无谓的优化我们是应该避免的，如图1-2：

图1-2
SQL Server中禁止并行的一些操作
上面我们了解了并行的操作性，但在SQL Server并不是所有操作都可以并行的，有些操作符会导致整个执行计划无法并行，而有些会使得某些分支(branch)无法并行，下面罗列出相关的操作符对并行的影响，这些感兴趣的朋友可以自行测试。
执行计划禁止并行
T-SQL scalar functions
更新表变量数据
访问系统表
动态游标
Branche不能并型
TOP（global）
2012以前窗口函数(Row_Number)
Multi -Statement Function
Backward scan
CTE递归
并行执行的优点
说了一些限制，我们再来简单说下优点，要不开此文章的意义何在。实际上在上半部分文章中大家可能已经感受到它的优点了，这里再简单总结下。实际上在并行中，计算工作是均匀的分配在参与并行的threads中，所有的threads同时工作，无先后之分。某些操作中threads自身的工作完成后还会协助threads工作，虽然会有短暂的CXPACKET等待(数据分布，预估等问题)但基本可以解决或是缓解。
执行时分支(Branchs)间有时可以是无顺序的，更好地增加了并行。
针对CPU-Bound的操作，SQL Server可以说时随着CPU(并行度)的增加，性能也基本是线性增加的。
并行相关的设置
SQL Server中有并行相关的一些设置，主要有两个：并行阈值及最大并行度。
并行阈值：上篇已经提到过，查询子树大小触发并行的条件，此值的设定仁者见仁智者见智了，一般设定为实例执行计划编译的平均查询子树大小上下幅度不超过20%
最大并行度：查询中的操作符可同时采用的线程数。这个值便随着NUMA的诞生应尤为注意，早在SQL 2005研发阶段，NUMA开始出现，而SQL 2005也提供了支持，但程度有限，随着SQLOS的进一步演化在SQL2008时对其支持已经很不错了，这里有大家都知道的NUMA架构下的foreign memory问题，实际上SQL Server在采用并行时会试图将并行的线程都集中在某个NUMA节点下，所以我们在配置初始参数时并行度最好控制在某个NUMA节点的核数内，而且最好是偶数，这里面涉及到很多SQLOS的知识，限于篇幅就不深入了。