发布于 2017-09-06 11:36:32 | 34 次阅读 | 评论: 0 | 来源: 网友投递

这里有新鲜出炉的SQL教程,程序狗速度看过来!

SQL 结构化查询语言

结构化查询语言(Structured Query Language)简称SQL(发音:/ˈɛs kjuː ˈɛl/ "S-Q-L"),结构化查询语言是一种数据库查询和程序设计语言,用于存取数据以及查询、更新和管理关系数据库系统;同时也是数据库脚本文件的扩展名。结构化查询语言是高级的非过程化编程语言,允许用户在高层数据结构上 工作。它不要求用户指定对数据的存放方法,也不需要用户了解具体的数据存放方式,所以具有完全不同底层结构的不同数据库系统, 可以使用相同的结构化查询语言作为数据输入与管理的接口。结构化查询语言语句可以嵌套,这使它具有极大的灵活性和强大的功能。


这篇文章主要介绍了SQL性能优化之定位网络性能问题的方法的相关资料,需要的朋友可以参考下

最近项目组同事跟我说遇到一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,很不科学。我帮了分析出了原因并得到解决。下面小编安装类似表结构,构造了一个案例,测试截图如下所示:

这个表有13800KB(也就是13M多大小),因为该表将图片保存到数据库(Item_Photo字段为iamge类型),这个是历史原因,暂且不喷这种的设计。看来这个SQL执行胜博發长的性能问题不在于IO和SQL本身执行计划是否有问题,而是在网络数据传胜博發上(服务器与客户端位于异地,两地专线带宽6M,不过很多应用、邮件、系统都依赖此专线)


sp_spaceused 'Item_Test' name rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB 

为了验证我的想法,我在服务器本机测试胜博發为2秒,如下截图所示

从上面我们知道在客户端执行完该SQL语句,总共耗费了2分23秒。那么客户端的到底获取了多少字节数据,数据传输耗费了多长胜博發呢? 能否查看这些DETAIL信息呢? 答案是可以。在SSMS工具栏,勾选“Include Client Statistics”或使用快捷键SHIFT+ALT+S,然后执行SQL语句,就能得到如下截图的相关信息。

Client Statistics(客户端信息)包含三大块: Query Profile Statistics, Network Statistics, Time Statistics。
这些部分的内容很容易理解,无需多说,那么我们来看看吧

Network Statistics(网络信息) Number of server roundtrips: 服务器往返的次数 TDS packets sent from client: 从客户端发送的TDS数据包(个数) TDS packets received from server: 从服务端接收的TDS数据包(个数) Bytes sent from client: 从客户端发送的字节数 Bytes received from server: 从服务器接收的字节数 Time Stattistics:(胜博發信息) Client processing time: 客户端处理胜博發 Total execution time: 总执行胜博發 Wait time on server replies: 服务器应答等待胜博發

从客户端发送的字节和从服务端接收的数据大小都很清晰、明了,那么数据从服务器端发送给客户端所需的胜博發这里没有,其实它基本上接近客户端处理胜博發(Client processing time),我们也可以将客户端处理胜博發权当网络数据传输胜博發,从上面案例,我们可以看到这个胜博發耗费了140秒(140132 ms),可以肯定这个SQL性能慢在网络数据传输上,而不是慢在数据库那一块(Server Processing Time).

我们来看看下图,这个是SQL SERVER的请求接收和数据输出的一个大致流程图,当客户端发送请求开始,当服务器接收客户端发来的最后一个TDS包,数据库引擎开始处理请求,请求完成后,将数据发送给客户端,从图中可以看出,客户端接收服务器端返回的数据也是需要一个过程的(或者说胜博發)


我们在SQL优化过程中,如果一个SQL出现性能问题时,我们应该站在一个全局的角度来分析问题,从CPU资源、网络带宽、磁盘IO、执行计划等多方面来分析,这样才能有助于你分析、定位问题根源,而不要只要SQL响应很慢时,就一味条件反射式先入为主:这是数据库问题。数据库也不能老背这个黑锅。

在数据库等待事件中,ASYNC_NETWORK_IO可以从另外一个侧面反映网络性能问题。关于ASYNC_NETWORK_IO等待类型:

This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application.

那么回到如何优化这个SQL的问题上来,我们可以从下面几个方面来进行优化。

1: SQL只取必须的字段数据

像这个案例,其实它根本不需要Item_Photo字段数据,那么我们可以修改SQL,只取我们需要的字段数据,就可以避免这个问题,提高SQL性能,另外根据我的经验,开发人员习惯性使用SELECT *,从不管那些数据是需要还是不需要的,先全部取过来再说,这种习惯性行为确实不是一个好习惯。

2:避免这种脑残设计

图片应该以文件形式保存在应用服务器上,数据库只保存其路径信息,这种将图片保存到数据库的设计纯属脑残行为。

以上所述是小编通过一个小demo给大家介绍的SQL性能优化之定位网络性能问题的方法,希望对大家有所帮助!



相关阅读 :
SQL性能优化之定位网络性能问题的方法(DEMO)
sql自动增长标识导致导入数据问题的解决方法
sql中参数过多利用变量替换参数的方法
SQL 查询和删除重复字段数据的方法
SQL 级联删除与级联更新的方法
数据库性能优化之SQL语句优化
SQL语句优化提高数据库性能
RAID的概念和RAID对于SQL性能的影响
SQL语句练习实例之五 WMS系统中的关于LIFO或FIFO的问题分析
五种提高 SQL 性能的方法
SQL 语句优化方法30例
SQL命令优化需要记住的9点事项
最新网友评论  共有(0)条评论 发布评论 返回顶部
月排行榜

Copyright © 2007-2017 PHPERZ.COM All Rights Reserved   冀ICP备14009818号  版权声明  服务