3.4 诊断间歇性问题（未完待续，老夫实在看不懂啊。。。。）《服务器性能剖析》

系统偶尔停顿或者慢查询，很难诊断

尽量不要使用试错的方式来解决问题（风险很大），无法定位问题，可能是测量的方式不正确，测量的点选择有误，工具不合适。例：

（1）通过慢的外部服务get数据

（2）大量请求落到MySQL 重新生成缓存条目

（3）DNS 查询偶尔超时（Domain Name System 域名和IP地址相互映射的一个分布式数据库）

（4）互斥锁争用，或内部删除查询缓存的算法效率太低

（5）并发度超过阈值，InnoDB 的y 扩展性限制导致查询计划的优化需要很长的时间。

3.4.1 单条查询问题还是服务器问题

服务器整体运行没有问题，某条查询偶尔变慢，查这条。

1.SHOW GLOBAL STATUS

对服务器影响小，花费时间不多

这个命令每秒捕获一次SHOW GLOBAL STATUS 的数据，输出给awk 计算并输出

每秒的查询数：出现尖刺，下跌。

Threads_connected ：用连接池，没有变化

Threads_running（正在执行查询的线程数）：上升

可能性：（1）服务器内部瓶颈，等待锁堆积，造成后端压力，出现排队问题。

（2）大量查询请求，memcached 失效

2.使用SHOW PROCESSLIST

观察是否有大量线程处于不正常，例如：查询很少会长时间处于“statistics”状态（服务器在查询优化阶段如何确定表关联的顺序，非常快）的。少会见到大量线程报告当前连接用户是“未经验证的用户（Unauthenticateduser）”，一般等待输入用于登录的用户信息才出现。

有很多线程处于查询执行的结束部分的状态：“freeing items”、end”、“cleaning up”和“logging slow query”。大量的线“freeingitems”查询有问题

很多查询处于“Locked”状态，是MyISAM 的一个典型问题，表级别锁定，写请求较多时，迅速导致服务器线程堆积。

3.使用查询日志

当遇到吞吐量突然下降时，看下降后完成的第一个查询（大多数时候），也可能连接被断开的现象，服务器重启导致

总结：尽量多用前两种，开销低