一般情况下，系统多多少少都会遇到点问题，那么遇到问题之后我们怎么定位原因呢？在这里我只说如何定位DB的问题。

看这篇文章有个前提：监控数据要完整！监控数据要完整！！监控数据要完整！！！
比如下面这个

乍一看，有个性能抖动，如何知道系统是不是有问题，可以通过以下途径知悉：

• 应用日志
• 监控报警
• 用户感知

无论是监控报警，还是用户感知，归根结底还得回归应用，从应用日志发现到底是哪个接口异常，接口异常的原因无外乎以下几种情况：

• 系统异常，比如超出负载
• 网络问题，比如网卡爆满，网络丢包
• io问题，比如刷磁盘，io调度算法设置问题
• 文件系统问题，比如内核bug
• DB问题，比如包含上面的几种情况，烂SQL问题

假如说上面几种情况排查完毕后没有异常，或者通过日志一眼就发现是DB问题，到底是什么问题呢？通常情况下，我会这样做：

1. 打开监控页面查看"性能"

如果没有监控，我也没办法了，只能根据应用报错猜了。

下面请睁大眼睛：
1. 查看出问题时间点整体性能
2. 通过异常，找出问题点
《医学的真相》说：“在医学中很多突破都是从研究例外开始。”

老罗也说“在平常的学习中，最珍贵的东西不是那些符合理论的东西，恰恰是那些看着奇怪，例外的东西，现有的理论往往解释不了，你千万不能忽略他，因为它是下一个创新的苗子。” 
这里也不例外，比如先看整体qps，tps有没有变化，网络有没有抖动等等，总之就是发现和其他时间段不一样的趋势。这个就是问题点所在，就拿第一张图举例子，我们看到rt飙高，一般来说rt飙高通常情况有以下几种原因：

• 烂SQL 线上90%以上基本是这个原因
• 硬件问题 线上出现过，但是不多
• 文件系统bug
• MySQL bug
• 网络问题

关于烂SQL其实有各种各样的，您可以到网上搜出一大堆，这里就不累述了，以后有时间的话，我可能会写写；

MySQL bug如果排除了烂SQL，有一些诡异的问题是可以怀疑是MySQL的bug的，可以查看bug list；

再次是网络问题，如果确定既不是烂SQL，系统的qps很高的话，如果系统有时不时的抖动，可以查看网络监控；

最后网络问题和文件系统问题出现的几率真是少之又少，但也不排除，只能具体问题具体分析了；

DB常见问题排查方法