一般情况下，系统多多少少都会遇到点问题，那么遇到问题之后我们怎么定位原因呢？在这里我只说如何定位DB的问题。
看这篇文章有个前提：监控数据要完整！监控数据要完整！！监控数据要完整！！！
比如下面这个
- 应用日志
- 监控报警
- 用户感知
无论是监控报警，还是用户感知，归根结底还得回归应用，从应用日志发现到底是哪个接口异常，接口异常的原因无外乎以下几种情况：
- 系统异常，比如超出负载
- 网络问题，比如网卡爆满，网络丢包
- io问题，比如刷磁盘，io调度算法设置问题
- 文件系统问题，比如内核bug
- DB问题，比如包含上面的几种情况，烂SQL问题
假如说上面几种情况排查完毕后没有异常，或者通过日志一眼就发现是DB问题，到底是什么问题呢？通常情况下，我会这样做：
- 打开监控页面查看"性能"
如果没有监控，我也没办法了，只能根据应用报错猜了。
下面请睁大眼睛：
1. 查看出问题时间点整体性能
2. 通过异常，找出问题点
《医学的真相》说：“在医学中很多突破都是从研究例外开始。”
老罗也说“在平常的学习中，最珍贵的东西不是那些符合理论的东西，恰恰是那些看着奇怪，例外的东西，现有的理论往往解释不了，你千万不能忽略他，因为它是下一个创新的苗子。”
这里也不例外，比如先看整体qps，tps有没有变化，网络有没有抖动等等，总之就是发现和其他时间段不一样的趋势。这个就是问题点所在，就拿第一张图举例子，我们看到rt飙高，一般来说rt飙高通常情况有以下几种原因：
- 烂SQL 线上90%以上基本是这个原因
- 硬件问题 线上出现过，但是不多
- 文件系统bug
- MySQL bug
- 网络问题
关于烂SQL其实有各种各样的，您可以到网上搜出一大堆，这里就不累述了，以后有时间的话，我可能会写写；
MySQL bug如果排除了烂SQL，有一些诡异的问题是可以怀疑是MySQL的bug的，可以查看bug list；
再次是网络问题，如果确定既不是烂SQL，系统的qps很高的话，如果系统有时不时的抖动，可以查看网络监控；
最后网络问题和文件系统问题出现的几率真是少之又少，但也不排除，只能具体问题具体分析了；
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
