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 date
as
begin
return @p_date
end

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

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

  翻翻你的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,不但要有过硬的技术,也要有足够的耐心,才能看清事物的本质。

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

以上所述是小编给大家介绍的SQL Server并行操作优化避免并行操作被抑制而影响SQL的执行效率,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!

时间: 2016-07-11

人工智能自动sql优化工具--SQLTuning for SQL Server

针对这种情况,人工智能自动SQL优化工具应运而生.现在我就向大家介绍这样一款工具:SQLTuning for SQL Server. 1. SQL Tuning 简介 SQL Turning是Quest公司出品的Quest Central软件中的一个工具. QuestCentral(图1)是一款集成化.图形化.跨平台的数据库管理解决方案,可以同时管理Oracle.DB2 和 SQL server 数据库.它包含了如下的多个工具: 数据库管理(DBA)  数据库监控(Monitoring Pack

SQL Server优化50法汇总

查询速度慢的原因很多,常见如下几种:1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2.I/O吞吐量小,形成了瓶颈效应.3.没有创建计算列导致查询不优化.4.内存不足5.网络速度慢6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8.sp_lock, sp_who, 活动的用户查看,原因是读写竞争资源.9.返回了不必要的行和列 10.查询语句不好,没有优化可以通过如下方法来优化查询 :1.把数据.日

优化 SQL Server 索引的小技巧

在本文中,我将说明如何用SQL Server的工具来优化数据库索引的使用,本文还涉及到有关索引的一般性知识. 关于索引的常识 影响到数据库性能的最大因素就是索引.由于该问题的复杂性,我只可能简单的谈谈这个问题,不过关于这方面的问题,目前有好几本不错的书籍可供你参阅.我在这里只讨论两种SQL Server索引,即clustered索引和nonclustered索引.当考察建立什么类型的索引时,你应当考虑数据类型和保存这些数据的column.同样,你也必须考虑数据库可能用到的查询类型以及使用的最为频

SQL Server中的SQL语句优化与效率问题

很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解.比如: select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan' 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那

SQL Server游标的使用/关闭/释放/优化小结

游标是邪恶的! 在关系数据库中,我们对于查询的思考是面向集合的.而游标打破了这一规则,游标使得我们思考方式变为逐行进行.对于类C的开发人员来着,这样的思考方式会更加舒服. 正常面向集合的思维方式是: 而对于游标来说: 这也是为什么游标是邪恶的,它会使开发人员变懒,懒得去想用面向集合的查询方式实现某些功能. 同样的,在性能上,游标会吃更多的内存,减少可用的并发,占用宽带,锁定资源,当然还有更多的代码量-- 从游标对数据库的读取方式来说,不难看出游标为什么占用更多的资源,打个比方: 当你从ATM取钱

SqlServer 索引自动优化工具

鉴于人手严重不足(当时算两个半人的资源),打消了逐个库手动去改的念头.当前的程序结构不允许搞革命的做法,只能搞搞改良,所以准备搞个自动化工具去处理.原型刚开发完,开会的时候以拿出来就遭到运维DBA团队强烈抵制,具体原因不详.最后无限延期.这里把思路分享下.欢迎拍砖. 整个思路是这样的,索引都是为查询和更新服务的,但是不合适的索引又会对插入和更新带来负面影响.面对表上现有的索引想识别那些是有效的不太可能.那么根据现有的数据使用情况重建所有的新索引不就解决了嘛.根据查询生成全新索引,然后和现有对比,

sql语句优化之SQL Server(详细整理)

MS SQL Server查询优化方法 查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,

ORACLE SQL语句优化技术要点解析

操作符优化: IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格. 但是用IN的SQL性能总是比较低的,从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别: ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询. 由此可见用IN的SQL至少多了一个转换的过程.一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了. 推荐方案:

SQL语句优化提高数据库性能

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化.为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN) 2)考虑使用临时表或表变量存放中间结果 3)少用子查询 4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜 一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出S

数据库SQL语句优化总结(收藏)

网上关于SQL优化的教程很多,但是比较杂乱.近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. 这篇文章我花费了大量的时间查找资料.修改.排版,希望大家阅读之后,感觉好的话推荐给更多的人,让更多的人看到.纠正以及补充. 1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id f

sql语句优化的一般步骤详解

前言 本文主要给大家分享了关于sql语句优化的一般步骤,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 一.通过 show status 命令了解各种 sql 的执行频率 mysql 客户端连接成功后,通过 show [session|global] status 命令可以提供服务器状态信息,也可以在操作系统上使用 mysqladmin extend-status 命令获取这些消息. show status 命令中间可以加入选项 session(默认) 或 global: se

SQL语句优化之JOIN和LEFT JOIN 和 RIGHT JOIN语句的优化

在数据库的应用中,我们经常需要对数据库进行多表查询,然而当数据量非常大时多表查询会对执行效率产生非常大的影响,因此我们在使用JOIN和LEFT JOIN 和 RIGHT JOIN语句时要特别注意: SQL语句的join原理: 数据库中的join操作,实际上是对一个表和另一个表的关联,而很多错误理解为,先把这两个表来一个迪卡尔积,然后扔到内存,用where和having条件来慢慢筛选,其实数据库没那么笨的,那样会占用大量的内存,而且效率不高,比如,我们只需要的一个表的一些行和另一个表的一些行,如果

常用SQL语句优化技巧总结【经典】

本文实例总结了常用SQL语句优化技巧.分享给大家供大家参考,具体如下: 除了建立索引之外,保持良好的SQL语句编写习惯将会降低SQL性能问题发生. ①通过变量的方式来设置参数 好: stringsql = "select * from people p where p.id = ? "; 坏: stringsql = "select * from people p where p.id = "+id; 数据库的SQL文解析和执行计划会保存在缓存中,但是SQL文只要有

SQL语句优化的一些必会指南

前言 怎么加快查询速度,优化查询效率,主要原则就是应尽量避免全表扫描,应该考虑在where及order by 涉及的列上建立索引. 建立索引不是建的越多越好,原则是: 第一:一个表的索引不是越多越好,也没有一个具体的数字,根据以往的经验,一个表的索引最多不能超过6个,因为索引越多,对update和insert操作也会有性能的影响,涉及到索引的新建和重建操作. 第二:建立索引的方法论为: 多数查询经常使用的列: 很少进行修改操作的列: 索引需要建立在数据差异化大的列上 利用以上的基础我们讨论一下如

Mysql查询最近一条记录的sql语句(优化篇)

下策--查询出结果后将时间排序后取第一条 select * from a where create_time<="2017-03-29 19:30:36" order by create_time desc limit 1 这样做虽然可以取出当前时间最近的一条记录,但是一次查询需要将表遍历一遍,对于百万以上数据查询将比较费时:limit是先取出全部结果,然后取第一条,相当于查询中占用了不必要的时间和空间:还有如果需要批量取出最近一条记录,比方说:"一个订单表,有用户,订