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

　　这个函数并没有什么实际意义，执行也非常简单，传入一个时间，返回这个时间，

　　当然这里只是为了下面的操作演示，你完全可以说我蛋疼，我只是为了演示并行被抑制的现象 　　翻翻你的SQL代码，有没有类似这种写法？

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

　　可以看到，并行操作和串行操作的效率差别还是很大的，对于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，这种情况，如果查询列上有索引，不仅仅是抑制索引，还会抑制并行

如何处理并行操作被抑制的情况： 

　　如果要解决类似这些个问题，该怎么办？    　　其实也很简单，建议查询条件通过函数运算之后赋值给一个变量，用变量去作为查询条件进行查询。 　　再次开始了愉快的并行，享受并行带来的快感。

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

总结：

　　本文通过一个简单的例子演示了并行操作被抑制的现象，说明了并行和串行在执行一个代价较大的SQL上的性能的巨大的差别 　　其中提到的查询方式是查询条件上因为函数的原因抑制了并行，完全区别于在查询列上使用函数抑制索引的情况。 　　并行查询可以充分调动CPU资源，以高效的方式完成查询，合理的利用并行会很大程度上提高SQL的执行效率。 　　为了利用好并行，在写SQL的时候，一定要注意，防止并行操作遭到抑制，给性能带来影响。

　　SQL优化是一个艰难而又反复的过程，即便如此，也乐在其中。 　　面对繁复SQL，不但要有过硬的技术，也要有足够的耐心，才能看清事物的本质。 　　对并行的理解还不够充分，有不对的地方希望各位看官指出，谢谢。

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

标签：有一个   混淆   server   ble   returns   无法   分享   设置   ret