SQL性能优化之定位网络性能问题的方法(DEMO)

最近项目组同事跟我说遇到一个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性能优化之定位网络性能问题的方法，希望对大家有所帮助！

赞 (0)

相关推荐

  • MySQL性能优化之Open_Table配置参数的合理配置建议

    在MySQL数据库中,Opened_tables表示打开过的表数量,下面将对MySQL Open_Table的合理配置作详细的说明介绍. MySQL Opened_tables表示打开过的表数量,下文就将教您如何合理配置MySQL Open_Table的值,希望对您学习MySQL数据库能有所帮助. MySQL Open_Table情况: 复制代码 代码如下: mysql> show global status like 'open%tables%';  +---------------+----

  • MySQL性能优化之路---修改配置文件my.cnf

    在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分.对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化,二是MySQL自身(my.cnf)的优化. 一.服务

  • mysql性能优化脚本mysqltuner.pl使用介绍

    MySQLTuner 下载地址:http://github.com/rackerhacker/MySQLTuner-perl MySQLTuner 使用方法: Downloading and using MySQLTuner is actually a very simple process: wget mysqltuner.pl perl mysqltuner.pl If you'd rather not invoke perl every time, just make it executa

  • MySQL性能优化配置参数之thread_cache和table_cache详解

    一.THREAD_CACHE MySQL里面为了提高客户端请求创建连接过程的性能,提供了一个连接池也就是 Thread_Cache池,将空闲的连接线程放在连接池中,而不是立即销毁.这样的好处就是,当又有一个新的请求的时候,mysql不会立即去创建连接 线程,而是先去Thread_Cache中去查找空闲的连接线程,如果存在则直接使用,不存在才创建新的连接线程. 有关Thread_Cache在MySQL有几个重要的参数,简单介绍如下: thread_cache_size Thread_Cache 中

  • MySQL性能优化

    1. 简介 在Web应用程序体系架构中,数据持久层(通常是一个关系数据库)是关键的核心部分,它对系统的性能有非常重要的影响.MySQL是目前使用最多的开源数据库,但是MySQL数据库的默认设置性能非常的差,仅仅是一个玩具数据库.因此在产品中使用MySQL数据库必须进行必要的优化.优化是一个复杂的任务,本文描述MySQL相关的数据库设计和查询优化,服务器端优化,存储引擎优化. 2. 数据库设计和查询优化 在MySQL Server性能调优中,首先要考虑的就是Database Schema设计,这一

  • MySQL性能优化之max_connections配置参数浅析

    MySQL的max_connections参数用来设置最大连接(用户)数.每个连接MySQL的用户均算作一个连接,max_connections的默认值为100.本文将讲解此参数的详细作用与性能影响. 与max_connections有关的特性 MySQL无论如何都会保留一个用于管理员(SUPER)登陆的连接,用于管理员连接数据库进行维护操作,即使当前连接数已经达到了max_connections.因此MySQL的实际最大可连接数为max_connections+1: 这个参数实际起作用的最大值

  • MySQL性能优化之table_cache配置参数浅析

    MySQL性能优化之table_cache配置参数浅析

    table_cache是一个非常重要的MySQL性能参数,它在5.1.3之后的版本中叫做table_open_cache.table_cache主要用于设置table高速缓存的数量.由于每个客户端连接都会至少访问一个表,因此此参数的值与max_connections有关. 缓存机制 当某一连接访问一个表时,MySQL会检查当前已缓存表的数量.如果该表已经在缓存中打开,则会直接访问缓存中的表已加快查询速度:如果该表未被缓存,则会将当前的表添加进缓存并进行查询. 在执行缓存操作之前,table_ca

  • MySQL性能优化的一些技巧帮助你的数据库

    你完成了你的品牌新的应用程序,一切工作就像一个魅力.用户来使用你的网络.每个人是幸福的. 然后,突然间,一个大爆发的用户杀死你的MySQL服务器,您的网站已关闭.出了什么问题?你怎么能阻止它吗? 以下是MySQL性能优化的一些技巧,将帮助你,帮助你的数据库. 大处着眼 在早期的发展阶段,你应该知道预期到您的应用程序的用户数.如果你希望很多用户来说,你应该想想大,从一开始,计划进行复制,可扩展性和性能. 但是,如果你优化你的SQL代码,架构和索引策略,也许你不会需要大环境.你必须总是三思而后行的性

  • MySQL DBA教程：Mysql性能优化之缓存参数优化

    数据库属于 IO 密集型的应用程序,其主要职责就是数据的管理及存储工作.而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级.所以,要优化数据库,首先第一步需要优化的就是 IO,尽可能将磁盘IO转化为内存IO.本文先从 MySQL 数据库IO相关参数(缓存参数)的角度来进行IO优化: 一.query_cache_size/query_cache_type (global)    Query cache 作用于整个 MySQL Inst

  • php导入大量数据到mysql性能优化技巧

    本文实例讲述了php导入大量数据到mysql性能优化技巧.分享给大家供大家参考.具体分析如下: 在mysql中我们结合php把一些文件导入到mysql中,这里就来分享一下我对15000条记录进行导入时分析与优化,需要的朋友可以参考一下. 之前有几篇文章,说了最近tiandi在帮朋友做一个小项目,用于统计电话号码的,每次按需求从数据库里随机生成打包的电话号码,然后不停地让人打这些电话号码推销产品(小小鄙视一下这样的行为).但是朋友要求帮忙,咱也不能不帮啊,是吧.程序两个星期前已经做好,测试完毕交工

随机推荐