还在写慢SQL？你不知道慢SQL，占用了你程序多少的性能

一 前言

不管是开发同学还是DBA,想必大家都遇到慢查询(select,update,insert,delete 语句慢)，影响业务稳定性。这里说的慢，有两个含义一是比正常的慢，有可能正常执行时间是10ms，异常的是100ms 。二是sql执行时间超过设置的慢查询标准比如500ms。

本文从IT架构以及数据库纬度来分析导致sql执行慢的原因/场景，抛砖引玉，有不足之处还请大家多多提建议。

二 基础知识

分析慢查询之前，我们先看看sql执行的路径,理清楚可能会影响sql执行速度的相关因素。

执行路径

app ---[proxy]---db

app --- db

目前大部分的数据库架构基本都是上面的路径，sql从app的应用服务器发起经过proxy然后到db，db执行sql进过proxy或者直接返回给app应用服务器。分析这个过程我们可以得到几个会影响sql执行速度的因素

1 网络，各个节点之间的网络2 OS系统 ，即数据库服务器3 MySQL数据库本身

三 基础系统层面

3.1 网络层面

1 网络丢包，重传

其实这个比较容易理解。当sql 从app端发送到数据库，执行完毕，数据库将结果返回给app端，这个将数据返回给app端的过程本质是网络包传输。因为链路的不稳定性，如果在传输过程中发送丢包会导致数据包重传，进而增加数据传输时间。从app端来看，就会觉得sql执行慢。

 

2 网卡满 比如大字段

这个场景可能不容易遇到，如果公司业务体量很大，比如平时每天300w订单的电商平台，平台大促(双十一，618)的时候极有可能出现网卡被打满。网卡带宽被占满类似各种节假日高速公路收费站(网卡)拥堵导致车流(数据包传输的速度)行动缓慢。

3 网络链路变长

该场景会影响应用纬度的一个事务比如交易下单整体耗时。

我们知道每个节点之间的数据传输是需要时间的，比如同城跨机房(15KM)之间的访问一般网络耗时1.5ms左右。

链路1 [app1]--调用--[app2]---[proxy]---[db] 相比 链路2[app1] -- [proxy] --[db]

执行一条sql请求会增加 [app1]--[app2]之间的网络传输耗时大约3ms。如果一个业务事件包含30个sql ，那么链路1要比链路2 多花至少90ms的时间成本。导致业务整体变慢。

3.2 受到影响IO的场景

1 磁盘io被其他任务占用

有些备份策略为了减少备份空间的使用，基于xtrabckup备份的时候 使用了compress选项将备份集压缩。当我们需要在数据库服务器上恢复一个比较大的实例，而解压缩的过程需要耗费cpu和占用大量io导致数据库实例所在的磁盘io使用率100%，会影响MySQL 从磁盘获取数据的速度，导致大量慢查询。

2 raid卡 充放电，raid 卡重置

RAID卡都有写cache(Battery Backed Write Cache),写cache对IO性能的提升非常明显,因为掉电会丢失数据,所以必须由电池提供支持。电池会定期充放电,一般为90天左右,当发现电量低于某个阀值时,会将写cache策略从writeback置为writethrough,相当于写cache会失效,这时如果系统有大量的IO操作,可能会明显感觉到IO响应速度变慢,cpu 队列堆积系统load飙高。下面是一个raid充放电导致sql慢查的案例。

root@rac1#megacli  -FwTermLog dsply -aALL11/08/143:36:58: prCallback: PR completed for pd=0a11/08/143:36:58: PR cycle complete11/08/143:36:58: EVT#