单条查询问题还是服务器问题（）
发现问题的蛛丝马迹了吗？如果有则首先要确认这是单条查询的问题还是服务器的问题这将为解决问题指出正确的方向如果服务器上所有的程序都突然变慢又突然都变好每一条查询也都变慢了那么慢查询可能就不一定是原因而是由于其他问题导致的结果反过来说如果服务器整体运行没有问题只有某条查询偶尔变慢就需要将注意力放到这条特定的查询上面
服务器的问题非常常见在过去几年硬件的能力越来越强配置 核或者更多CPU的服务器成了标配MySQL 在SMP 架构的机器上的可扩展性限制也就越来越显露出来尤其是较老的版本其问题更加严重而目前生产环境中的老版本还非常多新版本MySQL 依然也还有一些扩展性限制但相比老版本已经没有那么严重而且出现的频率相对小很多只是偶尔能碰到这是好消息也是坏消息好消息是很少会碰到这个问题坏消息则是一旦碰到则需要对MySQL 内部机制更加了解才能诊断出来当然这也意味着很多问题可以通过升级到MySQL 新版本来解决
那么如何判断是单条查询问题还是服务器问题呢？如果问题不停地周期性出现那么可以在某次活动中观察到或者整夜运行脚本收集数据第二天来分析结果大多数情况下都可以通过三种技术来解决下面将一一道来
使用SHOW GLOBAL STATUS
这个方法实际上就是以较高的频率比如一秒执行一次SHOW GLOBAL STATUS 命令捕获数据问题出现时则可以通过某些计数器（比如Threads_runningThreads_connectedQuestions 和Queries）的尖刺或者凹陷来发现这个方法比较简单所有人都可以使用（不需要特殊的权限）对服务器的影响也很小所以是一个花费时间不多却能很好地了解问题的好方法下面是示例命令及其输出
$ mysqladmin ext i | awk
/Queries/{q=$qp;qp=$}
/Threads_connected/{tc=$}
/Threads_running/{printf %d %d %d\n q tc $}
这个命令每秒捕获一次SHOW GLOBAL STATUS 的数据输出给awk 计算并输出每秒的查询数Threads_connected 和Threads_running（表示当前正在执行查询的线程数）这三个数据的趋势对于服务器级别偶尔停顿的敏感性很高一般发生此类问题时根据原因的不同和应用连接数据库方式的不同每秒的查询数一般会下跌而其他两个则至少有一个会出现尖刺在这个例子中应用使用了连接池所以Threads_connected 没有变化但正在执行查询的线程数明显上升同时每秒的查询数相比正常数据有严重的下跌
如何解析这个现象呢？凭猜测有一定的风险但在实践中有两个原因的可能性比较大其中之一是服务器内部碰到了某种瓶颈导致新查询在开始执行前因为需要获取老查询正在等待的锁而造成堆积这一类的锁一般也会对应用服务器造成后端压力使得应用服务器也出现排队问题另外一个常见的原因是服务区突然遇到了大量查询请求的沖击比如前端的memcached 突然失效导致的查询风暴
这个命令每秒输出一行数据可以运行几个小时或者几天然后将结果绘制成图形这样就可以方便地发现是否有趋势的突变如果问题确实是间歇性的发生的频率又较低也可以根据需要尽可能长时间地运行此命令直到发现问题再回头来看输出结果大多数情况下通过输出结果都可以更明确地定位问题
使用SHOW PROCESSLIST
这个方法是通过不停地捕获SHOW PROCESSLIST 的输出来观察是否有大量线程处于不正常的状态或者有其他不正常的特征例如查询很少会长时间处于statistics状态这个状态一般是指服务器在查询优化阶段如何确定表关联的顺序通常都是非常快的另外也很少会见到大量线程报告当前连接用户是未经验证的用户（Unauthenticateduser）这只是在连接握手的中间过程中的状态当客户端等待输入用于登录的用户信息的时候才会出现
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
