#### 慢日志诊断
在MySQL中,对于性能问题诊断,能够分析的一个入口就是日志
在系统层面,所能做的工作有限,因为MySQL是单进程多线程的架构,我们看到的连接是在线程层面的。 所以除了看到一个mysqld的进程CPU 100%之外,想要看到更多MySQL层面的信息就很有限了,所以系统层面的日志只能告诉你MySQL层面有资源问题,但是无法告诉你更多。
那么来看MySQL的错误日志,这个错误日志的信息也是有限,如果出现了SQL性能问题的时候,错误日志的粒度是无法探测到根因的,所以很可能通过日志看不到主要的错误,一旦出现的时候,其实问题已经是影响比较严重的了。
那么分析问题的一个必然之路就是MySQL层面提供的明细信息了,这个可以体现在通用日志或者慢日志层面。通用日志在极少数的情况下,才可能会去用,基本就是随用随开,用完即关,因为日志量大多数情况下都太大了。 那么选择其实就是慢日志了。
看慢日志的最终目的无非就是解决存在的,潜在的性能问题,如果问题没有发生,那就是潜在问题,只能通过慢日志去查看,查看的基准就是SQL的执行性能差一些。这个维度看起来有些缺少理论支撑,只追求短平快,但是细细想来也是合理有效。SQL问题无非体现在几个维度,**执行时间长**,**全表扫描**,**资源使用率高**,这几个维度,慢日志可以涵盖大多数,比如执行时间的问题,超过阈值就会记录,全表扫描的问题,如果没有走索引也会记录(有个参数 log_queries_not_using_indexes)
慢日志的分析工具:
1. mysqldumpslow
2. mysqlsla 基于perl
3. myprofi 基于php
4. mysql-explain-slow-log 基于perl
5. mysql-log-filter 基于python,php
6. pt-query-digest 基于perl
简单看下慢日志的一个演化方案
执行了3条SQL
select *from test; 执行2次
select *from cmdb_server; 执行1次
mysqlslowlog得到的结果如下:
```sh
Reading mysql slow query log from /data/mysql/dev01-slow.log
Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=586.0 (586), root[root]@localhost select *from cmdb_server
Count: 2 Time=0.00s (0s) Lock=0.00s (0s) Rows=3.0 (6), root[root]@localhost select *from test
```
其实是有些简陋的
pt-query-digest的结果,就会看到专业的输出
![image.png](https://upload-images.jianshu.io/upload_images/20607552-1a8706551c981c8e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
报告有个很核心的概念就是response time,里面的很多概念都会基于时间维度来进行统计,比如执行时间(Exec time),锁定时间(Locak time)等指标可以快速地得到整个慢日志的概览信息
对于慢日志的Profile部分,其实是个排行榜,通过这个榜单可以快速的定位瓶颈SQL,报告后面是每一条SQL的详细信息