高性能MySQL：剖析服务器负载（1）[1]

剖析服务器负载（）

服务器端的剖析很有价值因为在服务器端可以有效地审计效率低下的查询定位和优化坏查询能够显着地提升应用的性能也能解决某些特定的难题还可以降低服务器的整体压力这样所有的查询都将因为减少了对共享资源的争用而受益（间接的好处）降低服务器的负载也可以推迟或者避免升级更昂贵硬件的需求还可以发现和定位糟糕的用户体验比如某些极端情况

MySQL 的每一个新版本中都增加了更多的可测量点如果当前的趋势可靠的话那么在性能方面比较重要的测量需求很快能够在全球范围内得到支持但如果只是需要剖析并找出代价高的查询就不需要如此复杂有一个工具很早之前就能帮到我们了这就是慢查询日志

捕获MySQL 的查询到日志文件中

在MySQL 中慢查询日志最初只是捕获比较慢的查询而性能剖析却需要针对所有的查询而且在MySQL 及之前的版本中慢查询日志的响应时间的单位是秒粒度太粗了幸运的是这些限制都已经成为历史了在MySQL 及更新的版本中慢日志的功能已经被加强可以通过设置long_query_time 为 来捕获所有的查询而且查询的响应时间单位已经可以做到微秒级如果使用的是Percona Server那么 版本就具备了这些特性而且Percona Server 提供了对日志内容和查询捕获的更多控制能力

在MySQL 的当前版本中慢查询日志是开销最低精度最高的测量查询时间的工具如果还在担心开启慢查询日志会带来额外的I/O 开销那大可以放心我们在I/O 密集型场景做过基准测试慢查询日志带来的开销可以忽略不计（实际上在CPU 密集型场景的影响还稍微大一些）更需要担心的是日志可能消耗大量的磁盘空间如果长期开启慢查询日志注意要部署日志轮转（log rotation）工具或者不要长期启用慢查询日志只在需要收集负载样本的期间开启即可

MySQL 还有另外一种查询日志被称之为通用日志但很少用于分析和剖析服务器性能通用日志在查询请求到服务器时进行记录所以不包含响应时间和执行计划等重要信息MySQL 之后支持将日志记录到数据库的表中但多数情况下这样做没什么必要这不但对性能有较大影响而且MySQL 在将慢查询记录到文件中时已经支持微秒级别的信息然而将慢查询记录到表中会导致时间粒度退化为只能到秒级而秒级别的慢查询日志没有太大的意义

Percona Server 的慢查询日志比MySQL 官方版本记录了更多细节且有价值的信息如查询执行计划锁I/O 活动等这些特性都是随着处理各种不同的优化场景的需求而慢慢加进来的另外在可管理性上也进行了增强比如全局修改针对每个连接的long_query_time 的阈值这样当应用使用连接池或者持久连接的时候可以不用重置会话级别的变量而启动或者停止连接的查询日志总的来说慢查询日志是一种轻量而且功能全面的性能剖析工具是优化服务器查询的利器

有时因为某些原因如权限不足等无法在服务器上记录查询这样的限制我们也常常碰到所以我们开发了两种替代的技术都集成到了Percona Toolkit 中的ptquerydigest 中第一种是通过processlist 选项不断查看SHOW FULL PROCESSLIST 的输出记录查询第一次出现的时间和消失的时间某些情况下这样的精度也足够发现问题但却无法捕获所有的查询一些执行较快的查询可能在两次执行的间隙就执行完成了从而无法捕获到

第二种技术是通过抓取TCP 网络包然后根据MySQL 的客户端/ 服务端通信协议进行解析可以先通过tcpdump 将网络包数据保存到磁盘然后使用ptquerydigest 的type=tcpdump 选项来解析并分析查询此方法的精度比较高并且可以捕获所有查询还可以解析更高级的协议特性比如可以解析二进制协议从而创建并执行服务端预解析的语句（prepared statement）及压缩协议另外还有一种方法就是通过MySQLProxy 代理层的脚本来记录所有查询但在实践中我们很少这样做

[] []