SQL性能优化：如何定位网络性能问题

   <p>一同事跟我反馈他遇到了一个SQL性能问题，他说全表只有69条记录，客户端执行耗费了两分多钟，这不科学呀。要我分析一下原因并解决。我按照类似表结构，构造了一个案例，测试截图如下所示</p>    <p><img src="https://simg.open-open.com/show/88ff0ddfb4990ef4632a17af7af16f20.png"></p>    <p>这个表有13800KB（也就是13M多大小），因为该表将图片保存到数据库（Item_Photo字段为iamge类型），这个是历史原因，暂且不喷这种的设计。看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题，而是在网络数据传时间上（服务器与客户端位于异地，两地专线带宽6M，不过很多应用、邮件、系统都依赖此专线）</p>    <pre>  sp_spaceused 'Item_Test'</pre>    <pre>  name               rows     reserved        data        index_size      unused</pre>    <pre>  -----------  -------------  ----------  -------------- ----------- -------------</pre>    <pre>  Item_Test          69      13864 KB      13800 KB           16 KB        48 KB</pre>    <p>为了验证我的想法，我在服务器本机测试时间为2秒，如下截图所示</p>    <p><img src="https://simg.open-open.com/show/343e178bcec63e31f7f6db1b4a7cd8d7.png"></p>    <p>从上面我们知道在客户端执行完该SQL语句，总共耗费了2分23秒。那么客户端的到底获取了多少字节数据，数据传输耗费了多长时间呢？ 能否查看这些DETAIL信息呢？ 答案是可以。在SSMS工具栏，勾选“Include Client Statistics”或使用快捷键SHIFT+ALT+S，然后执行SQL语句，就能得到如下截图的相关信息。</p>    <p><img src="https://simg.open-open.com/show/d5750618a99141a0a1f3d606dfb6696d.png"></p>    <p><img src="https://simg.open-open.com/show/f4623646f54889f1dda3d53f9d2e0f79.png"></p>    <p>Client Statistics(客户端统计信息）包含三大块：  Query Profile Statistics， Network Statistics, Time Statistics。</p>    <p>这些部分的内容很容易理解，无需多说，那么我们来看看吧</p>    <pre>  Network Statistics（网络统计信息）</pre>    <pre>  Number of server roundtrips:        服务器往返的次数</pre>    <pre>  TDS packets sent from client:       从客户端发送的TDS数据包（个数）</pre>    <pre>  TDS packets received from server:   从服务端接收的TDS数据包（个数）</pre>    <pre>  Bytes sent from client:             从客户端发送的字节数</pre>    <pre>  Bytes received from server:         从服务器接收的字节数</pre>    <pre>  Time Stattistics:（时间统计信息）</pre>    <pre>  Client processing time:              客户端处理时间</pre>    <pre>  Total execution time:                总执行时间</pre>    <pre>  Wait time on server replies:         服务器应答等待时间</pre>    <p>从客户端发送的字节和从服务端接收的数据大小都很清晰、明了，那么数据从服务器端发送给客户端所需的时间这里没有，其实它基本上接近客户端处理时间（Client processing time），我们也可以将客户端处理时间权当网络数据传输时间，从上面案例，我们可以看到这个时间耗费了140秒（140132 ms）,可以肯定这个SQL性能慢在网络数据传输上，而不是慢在数据库那一块（Server Processing Time）.</p>    <p>我们来看看下图，这个是SQL SERVER的请求接收和数据输出的一个大致流程图，当客户端发送请求开始，当服务器接收客户端发来的最后一个TDS包，数据库引擎开始处理请求，请求完成后，将数据发送给客户端，从图中可以看出，客户端接收服务器端返回的数据也是需要一个过程的（或者说时间）</p>    <p><img src="https://simg.open-open.com/show/de3f84ad31a19a8756d3a3d8620f4c07.png"></p>    <p>我们在SQL优化过程中，如果一个SQL出现性能问题时，我们应该站在一个全局的角度来分析问题，从CPU资源、网络带宽、磁盘IO、执行计划等多方面来分析，这样才能有助于你分析、定位问题根源，而不要只要SQL响应很慢时，就一味条件反射式先入为主：这是数据库问题。数据库也不能老背这个黑锅。</p>    <p>在数据库等待事件中，ASYNC_NETWORK_IO可以从另外一个侧面反映网络性能问题。关于ASYNC_NETWORK_IO等待类型：</p>    <p>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.</p>    <p>那么回到如何优化这个SQL的问题上来，我们可以从下面几个方面来进行优化。</p>    <p>1： SQL只取必须的字段数据</p>    <p>像这个案例，其实它根本不需要Item_Photo字段数据，那么我们可以修改SQL，只取我们需要的字段数据，就可以避免这个问题，提高SQL性能，另外根据我的经验，开发人员习惯性使用SELECT *，从不管那些数据是需要还是不需要的，先全部取过来再说，这种习惯性行为确实不是一个好习惯。</p>    <p>2：避免这种脑残设计</p>    <p>图片应该以文件形式保存在应用服务器上，数据库只保存其路径信息，这种将图片保存到数据库的设计纯属脑残行为。</p>    <p>参考资料：</p>    <p><a href="/misc/goto?guid=4959670518588115711" rel="nofollow,noindex">https://www.simple-talk.com/sql/database-administration/how-come-the-hourglass-why-database-applications-slow-down.-/ </a></p>    <p>来自： <a href="/misc/goto?guid=4959670518676373735" rel="nofollow">http://www.cnblogs.com/kerrycode/p/5386626.html</a></p>