100ms的SQL把伺服器搞崩潰了

乙個專案上線了兩個月，除了一些反饋的優化和小bug之外，專案一切順利；前期是屬於推廣階段，可能使用人員沒那麼多，當然對於專案部署肯定提前想到併發量了，所以早就把集群安排上，而且還在測試環境搞了一下壓測，絕對是沒得問題的；但是，就在兩個月後的一天，系統突然跑的比烏龜還慢，投訴開始就陸續反饋過來了。

經過排查，原來是頻繁執行一條耗時100ms的sql導致，100ms感覺不長，但就是把系統搞崩了，具體細節如下。

1. 專案概況

專案採用abp進行開發，整合統一的認證中心(ids4)，部分資料對接第三方系統，拆分後的這個專案架構相對簡單。

考慮併發量不高，就算是高峰期也不會超過1000，於是就搞了個單台的資料庫伺服器(mysql)，測試環境中經過壓測，完全能抗住。

上線時，由於線上資源的關係，db伺服器的配置沒有按測試環境的標準來分配，相關人員想著後續看情況進行補配。上線推的比較緊，簡單評估了配置風險，初步判斷沒啥大問題，於是就推上線了。

由於系統相對不大，並沒有把分布式日誌、排程監控，效能監控整合上去。

2. 問題排查

上線期間，前期處於使用推廣階段，一切正常。兩個月後的一天，系統處於使用高峰時段，突然陸續收到反饋：系統有點卡！！！於是趕緊進行排查。

由於系統已經是集群部署的，慢這個問題首先懷疑是資料庫伺服器，於是讓dba的同事排查了一下，沒有鎖，只是有大量事務等待提交(waiting for handler commit)，通過如下命令可查的：

# 檢視正在執行的指令碼 select * from information_schema.processlist t where t.command != 'sleep' order by time desc;

看到都是插入審計日誌記錄導致，一看日誌記錄頻率，差不多一秒500條記錄。dba同事說可能是記錄插入頻繁導致，此時cpu已經爆到100%了，為了快速解決問題，於是就趕緊關掉了一些不必要的日誌記錄。

這麼一改，稍微降了一點，沒有事務提交的記錄，系統勉強可以撐著用，但是cpu還是在85%~97%波動；

看到這種情況，當然還是不放心，繼續排查。中間有對伺服器的配置產生過懷疑，但非常肯定的是這不是主要原因，於是和dba的同事繼續排查。

系統雖然可以正常使用，但時不時的也看看監控屏，cpu一直處於高水位狀態，還是有點慌的，因為一有問題，資訊和**都要爆。

突然dba同事發現有乙個單錶查詢的sql執行比較頻繁，於是單獨拿出來試了一下，查詢時間150ms左右，這個表的資料量不大，8萬左右，但沒有加任何索引，因為想著資料量不大，查詢時長還可接受，所以當時就沒有加相關索引。

定位到這條sql後，想到的第一步就是增加索引，在測試環境上試了一把，執行效率直接飛速提高到1ms；效果如下：

所以和dba同事達成一致意見，在生成環境上增加復合索引(建立索引一定要注意字段順序)，在中午時候，系統使用頻率不太高，於是就在生成上快速加了索引，我去，cpu一下降到了20%以內，意不意外；就算在使用高峰期，也沒超過20%，通過zabbix工具監控看到cpu的效果：

問題算是解決了，總算松了一口氣。

系統雖小，問題不大，但其實暴露的問題還是挺多。

關注「code綜藝圈」，和我一起學習吧。