SQL Server 并行操作优化，避免并行操作被抑制而影响SQL的执行效率

kution

　　为什么我也要说SQL Server的并行：
　　这几天园子里写关于SQL Server并行的文章很多，不管怎么样，都让人对并行操作有了更深刻的认识。
　　我想说的是：尽管并行操作可能（并不是一定）存在这样或者那样的问题，但是我们不能否认并行，仍然要利用好并行。
　　但是，实际开发中，某些SQL语句的写法会导致用不到并行，从而影响到SQL的执行效率
　　所以，本文要表达的是：我们要利用好并行，不要让一些SQL的写法问题“抑制”了并行，让我们享受不了并行带来的快感
　　关于SQL Server的并行：
　　所谓的并行，指SQL Server对于那些执行代价相对较大（这个相对跟你的设置有关）的SQL时，如果数据库服务器存在多颗CPU，
　　SQL Server查询引擎会采用并行的方式，也即采用多颗CPU参与整个运算过程，每颗CPU“分担”一部分计算任务，最后汇总合并各个CPU的计算的一种行为
　　有时候，不当的并行查询不但不会加快查询的速度，想反会拖慢查询的效率，如果采用不当的并行操作，甚至会影响到整个服务器的稳定性。
　　所以SQL Server 究竟在多大代价下启用并行，是由配置的，这个配置可根据具体的情况做修改，有人说这个值的单位是“秒”，貌似没见过权威的资料说过到底单位是什么，这里暂不追究
　　有清楚这个阈值单位的园友情不惜赐教，谢了

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711215814482-1451752250.jpg

　　尽管并行操作可能存在这样活着那样的问题，但是我们不能因噎废食，利用好并行，往往总是利大于弊。
　　但是并不是所有的执行代价较大SQL都能用到并行操作，实际开发中，有一些SQL的写法会抑制到并行操作，结果，导致整个SQL语句（存储过程）的效率上不去。
　　下面来举例说明。
　　并行查询是如何变成了串行的：
　　如下是一个非常简单的查询操作，这些写法下，默认情况下开启了并行，可以看到，一共开启了8个线程来对SQL语句做计算。

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711221211045-820167138.jpg

　　当然这SQL的执行效率还算不错，CPU时间是622毫秒，执行总时间是130毫秒，
　　这里不要弄混淆了，CPU时间的633毫秒，是8个CPU一共消耗的CPU时间，大于总的执行130毫秒很正常的

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711221417904-1185059275.jpg

　　下面创建一个非常简单的函数，
CREATE function [dbo].[fn_justFunction](@p_date date)returns dateasbegin　　
    return @p_dateend
　　这个函数并没有什么实际意义，执行也非常简单，传入一个时间，返回这个时间，

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711221915904-34925321.png

　　当然这里只是为了下面的操作演示，你完全可以说我蛋疼，我只是为了演示并行被抑制的现象
　　翻翻你的SQL代码，有没有类似这种写法？
　　然后我们这么写这个查询，就是在查询条件上这么处理CreateDate>dbo.fn_justFunction('2015-1-1')（注意不是表的列，而是函数作用在查询条件上），
　　注意这个函数并不影响任何查询结果，传入的2015-1-1，返回位依旧是2015-1-1，但是这么一变化，并行就变成串行的了，
　　SQL执行期间只有一个CPU飚了起来，使用了到达80%左右，，与此同时其他CPU跟没事人一样，也不上来帮忙，还是很闲
　　还记得上面并行操作方式执行时间是多少么？130毫秒，现在粗看起来是多少，这里是4S,也就是4000毫秒

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711222859029-2088842914.jpg

　　可以看到，并行操作和串行操作的效率差别还是很大的，对于CPU的利用也不充分（当然我不是强调一定要用满所有的CPU才算合理）
　　再次强调一点，这里并不是在表的字段上加函数抑制了索引什么的，纯粹的影响到的是并行操作。
　　当然，抑制并行的写法不单单是在查询条件在使用函数，实际开发中，影响会更大，
　　因为实际业务中数据有可能会更大，SQL也可能更加复杂，这种情况可能更加难以甄别。
　　比如连接条件上，如下，连接条件上使用函数导致无法使用并行的情况，也是实际开发中遇到的
　　select * from TableA a inner join TableB b on a.id=b.id and a.Column=dbo.function(@Variable) where ***
　　当然抑制到并行操作的不单单只有这两种写法，还有可能潜在其他类似的写法也会影响到并行查询。
　　这就要求我们在写SQL的时候，不但要注意不能再字段上使用函数（无法使用该字段上的索引），同样，查询条件上也尽可能不要使用函数，有可能影响到并行操作。
　　总结起来有一下几种情况会抑制到并行的使用（以后发现再更新）：
　　1，将函数之类的操作作用在查询条件上
　　比如：CreateDate>dbo.fn_justFunction('2015-1-1')
　　2，将函数之类的操作作用在连接条件上
　　比如：select * from TableA a inner join TableB b on a.id=b.id and a.Column=dbo.function(@Variable)  where ***
　　3，强函数之类的操作作用在查询列上
　　比如：FunctionName(ColumnName)>55，这种情况，如果查询列上有索引，不仅仅是抑制索引，还会抑制并行
　　如何处理并行操作被抑制的情况：
　　如果要解决类似这些个问题，该怎么办？
　　其实也很简单，建议查询条件通过函数运算之后赋值给一个变量，用变量去作为查询条件进行查询。
　　再次开始了愉快的并行，享受并行带来的快感。

http://images2015.cnblogs.com/blog/380271/201607/380271-20160711230759264-553370435.png

　　对于连接条件上的函数处理也类似，将结果计算出来之后，保存在一个变量中，把变量写在连接条件中，
　　当然可能有其他办法，我暂时还没有想到。