MySQL DBA工作突围的一个入口-慢日志
这是学习笔记的第 1725 篇文章
在MySQL中，对于性能问题诊断，最开始的时候总是感觉有些束手无策，如果一个人问你，MySQL数据库响应慢了，该怎么办，如果数据库服务器CPU 100%了该怎么吧，或者数据库连接不上了，业务提示无法连接该怎么办，看起来好像没有太大的关系的问题，其实我们能够分析的一个入口就是日志。
在系统层面，其实所能做的工作实在有限，因为MySQL是单进程多线程的架构，我们看到的连接是在线程层面的。 所以除了看到一个mysqld的进程CPU 100%之外，我们想要看到更多MySQL层面的信息就很有限了，所以系统层面的日志只能告诉你MySQL层面有资源问题，但是无法告诉你更多。
那么来看MySQL的错误日志，这个错误日志的信息也是有限，如果出现了SQL性能问题的时候，错误日志的粒度是无法探测到根因的，所以很可能我们通过日志看不到主要的错误，一旦出现的时候，其实问题已经是影响比较严重的了。
那么我们分析问题的一个必然之路就是MySQL层面提供的明细信息了，这个可以体现在通用日志或者慢日志层面。通用日志在极少数的情况下，我们才可能会去用，基本就是随用随开，用完即关，因为日志量大多数情况下都太大了。 那么我们的选择其实就是慢日志了，你想想到了这个时候，你还能够参考什么。
在Oracle里面有一个性能诊断模型是OWI,是基于等待事件所做的分析，里面有经典的3A工具（AWR,ASH,ADDM）， 看 起来和MySQL不搭边，所幸的是MySQL的sys schema就是一个好的开始，等待事件也补充起来了。 这让我看到了一个Oracle 9i版本迭代的过程，9i想当年也是一个很经典的版本，也是风尘仆仆的迈过了10g,11g,到了现在的cloud,(12c,18c,19c...).
MySQL在短时间内不会出现经典的3A工具，但是慢日志就是我们改善DBA现状的一把利器。 慢日志层面分析好了，那么我们的工作现状就会大大改善 。
我提两个问题大家思考一下，是不是开发同学很多时候都希望DBA提供慢日志供他们参考，或者DBA也希望做一些慢日志的分析（无论是在线还是离线）。这其实是两个维度的工作，但是都指向了同一个终点，那就是性能优化。 看慢日志的最终目的无非就是解决存在的，潜在的性能问题，如果问题没有发生，那就是潜在问题，我们只能通过慢日志去查看，查看的基准就是SQL的执行性能差一些。这个维度看起来有些缺少理论支撑，只追求短平快，但是细细想来也是合理有效。SQL问题无非体现在几个维度，执行时间长，全表扫描，资源使用率高，这几个维度，慢日志可以涵盖大多数，比如执行时间的问题，超过阈值就会记录，全表扫描的问题，如果没有走索引也会记录（有个参数 log_queries_not_using_indexes）
慢日志的分析工具有多少呢，简单来说有这么些。
mysqldumpslow
mysqlsla 基于perl
myprofi 基于php
mysql-explain-slow-log 基于perl
mysql-log-filter 基于python,php
pt-query-digest 基于perl
第1个mysqldumpslow是原生的，其他的都是第三方的。
还有第三方的平台，比如开源工具 Anemometer
github链接是 https://github.com/box/Anemometer
一个项目如果star过千，已经能够说明有一定的影响力了。
当然还有很多基于ES的方案。
我们来简单看下慢日志的一个演化方案。
我执行了3条SQL
select *from test; 执行2次
select *from cmdb_server; 执行1次
mysqlslowlog得到的结果如下：
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的结果，就会看到专业的输出。
里面有个很核心的概念就是response time.
有了这个我们就可以做更多的性能问题诊断了。
比如文件过大，按照时间范围来统计
考虑同比环比
考虑快照
考虑SQL排行榜
集群环境的SQL问题