你的位置:首页 > 数据库

[数据库]SQL Server 并行操作优化,避免并行操作被抑制而影响SQL的执行效率


 

为什么我也要说SQL Server的并行:

这几天园子里写关于SQL Server并行的文章很多,不管怎么样,都让人对并行操作有了更深刻的认识。

我想说的是:尽管并行操作可能(并不是一定)存在这样或者那样的问题,但是我们不能否认并行,仍然要利用好并行。

但是,实际开发中,某些SQL语句的写法会导致用不到并行,从而影响到SQL的执行效率

所以,本文要表达的是:我们要利用好并行,不要让一些SQL的写法问题“抑制”了并行,让我们享受不了并行带来的快感

 

关于SQL Server的并行:

所谓的并行,指SQL Server对于那些执行代价相对较大(这个相对跟你的设置有关)的SQL时,如果数据库服务器存在多颗CPU,

SQL Server查询引擎会采用并行的方式,也即采用多颗CPU参与整个运算过程,每颗CPU“分担”一部分计算任务,最后汇总合并各个CPU的计算的一种行为

有时候,不当的并行查询不但不会加快查询的速度,想反会拖慢查询的效率,如果采用不当的并行操作,甚至会影响到整个服务器的稳定性。

所以SQL Server 究竟在多大代价下启用并行,是由配置的,这个配置可根据具体的情况做修改,有人说这个值的单位是“秒”,貌似没见过权威的资料说过到底单位是什么,这里暂不追究

有清楚这个阈值单位的园友情不惜赐教,谢了

 

 

尽管并行操作可能存在这样活着那样的问题,但是我们不能因噎废食,利用好并行,往往总是利大于弊。

但是并不是所有的执行代价较大SQL都能用到并行操作,实际开发中,有一些SQL的写法会抑制到并行操作,结果,导致整个SQL语句(存储过程)的效率上不去。

下面来举例说明。

 

并行查询是如何变成了串行的:

  如下是一个非常简单的查询操作,这些写法下,默认情况下开启了并行,可以看到,一共开启了8个线程来对SQL语句做计算。

  

 

  当然这SQL的执行效率还算不错,CPU时间是622毫秒,执行总时间是130毫秒,

  这里不要弄混淆了,CPU时间的633毫秒,是8个CPU一共消耗的CPU时间,大于总的执行130毫秒很正常的

  

 

  下面创建一个非常简单的函数,

CREATE function [dbo].[fn_justFunction](@p_date date)returns dateasbegin  return @p_dateend

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

  

  

  当然这里只是为了下面的操作演示,你完全可以说我蛋疼,我只是为了演示并行被抑制的现象

  翻翻你的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的时候,不但要注意不能再字段上使用函数(无法使用该字段上的索引),同样,查询条件上也尽可能不要使用函数,有可能影响到并行操作。

 

 

如果处理并行操作被抑制的情况: 

  如果要解决类似这些个问题,该怎么办?其实也很简单,建议查询条件通过函数运算之后赋值给一个变量,用变量去作为查询条件进行查询。

  再次开始了愉快的并行,享受并行带来的快感。

  

 

  对于连接条件上的函数处理也类似,将结果计算出来之后,保存在一个变量中,把变量写在连接条件中,

  当然可能有其他办法,我暂时还没有想到。

 

 

总结:

  本文通过一个简单的例子演示了并行操作被抑制的现象,说明了并行和串行在执行一个代价较大的SQL上的性能的巨大的差别

  其中提到的查询方式是查询条件上因为函数的原因抑制了并行,完全区别于在查询列上使用函数抑制索引的情况。

  并行查询可以充分调动CPU资源,以高效的方式完成查询,合理的利用并行会很大程度上提高SQL的执行效率。

  为了利用好并行,在写SQL的时候,一定要注意,防止并行操作遭到抑制,给性能带来影响。

 

 

  SQL优化是一个艰难而又反复的过程,即便如此,也乐在其中。

  面对繁复SQL,不但要有过硬的技术,也要有足够的耐心,才能看清事物的本质。

  对并行的理解还不够充分,有不对的地方希望各位看官指出,谢谢。

 

出处:http://www.cnblogs.com/wy123/p/5661848.html