一般情況下，系統多多少少都會遇到點問題，那麼遇到問題之後我們怎麼定位原因呢？在這裡我隻說如何定位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很高的話，如果系統有時不時的抖動，可以檢視網絡監控；
最後網絡問題和檔案系統問題出現的幾率真是少之又少，但也不排除，隻能具體問題具體分析了；