問題：

某數(shù)據(jù)庫持續(xù)報警，系統(tǒng)負載過高，達到160左右。

初步分析：

1）查看監(jiān)控

數(shù)據(jù)庫并發(fā) QPS 15000/s ，連接數(shù)保持2800左右。

sys load 70%，us cpu 20%-----→ 很奇怪，sys load 負載高，說明函數(shù)使用過多，上下文切換？ io 資源不夠用？?

2）數(shù)據(jù)庫參數(shù)

innodb_thread_concurrency=0?--→ 不做限制？ ?但是cpu 核數(shù)是固定的，業(yè)務并發(fā)又高?？隙ㄓ袉栴}

?測試該參數(shù)設置為1（限制同時只能跑一個線程）后，30s 左右，系統(tǒng)可能會恢復正常。

然后再設置為0，過一會又出問題。 ? ?--→?更說明這個參數(shù)設置不合理

3）?show engine innodb status\G

? ? ? ?看到很多線程在 opening table、sending data、 copy to tmp table，sorting result 狀態(tài)

? ? ? 設置?table_open_cache=1000，tmp_table_size=64M，不起作用。

4）相關sql語句

語句1：?

? ? ? 相關sql 的表索引都是單字段索引。走了索引，每個sql 還需要掃描幾十條記錄。

? ? ? 加了復合索引后，系統(tǒng)負載立馬恢復正常。 問題解決了？

? ? ? 為了驗證確實是這個索引導致的。 于是決定把索引刪了?。。。?！

? ? ? 這一刪，發(fā)現(xiàn)并發(fā)太高，根本刪不掉，反而系統(tǒng)負載又飚起來，比之前還高。

? ? ? 不停的告警中?。。。。?/b>

語句2：?

? ? ? ?如下圖，app_id 索引已經(jīng)有了，每個sql還需要掃描8000多行數(shù)據(jù)。?

? ? ? ?查看表結構，發(fā)現(xiàn)有一個大字段類型text

? ? ? ?同時慢日志不停的打印這個sql。 ? ? ---→ 聯(lián)想到上面的sql 狀態(tài)都是?sending data、 copy to tmp table 是有原因的。

? ? ? ? ?趕緊聯(lián)系開發(fā)，修改邏輯，sql 查詢時，不返回該大字段。

? ? ? ? ?但是系統(tǒng)負載依舊。。。。。沒有緩解?。。?！

?語句3：

? ? ? ? ? ?發(fā)現(xiàn)在processlist 中有498條SQL 在執(zhí)行，很普通的sql，正常應該執(zhí)行很快，但是已經(jīng)執(zhí)行了1h 左右。 ?

? ? ? ? ? sending data、 copy to tmp table，sorting result 狀態(tài). ?

? ? ? ? ? 于是KILL ， ?但是kill 殺不掉。系統(tǒng)負載進一步加劇。。。。。。。

5）、聯(lián)系業(yè)務，重啟DB。?

? ? ? ? ?killed 狀態(tài)的線程 停不了， 只能kill mysql 進程。

? ? ? ? ?重啟mysql 后，截止第二天12點，系統(tǒng)負載一直保持正常狀態(tài)。（如下圖）

總結：

1、高并發(fā)系統(tǒng)，??innodb_thread_concurrency=0 ?不做限制，設置不合理，必須降低io 的并發(fā)。

2、索引不合適，需要及時調(diào)整

3、大字段類型，不能頻繁的出現(xiàn)查詢SQL中，尤其是高并發(fā)的系統(tǒng)。

4、高并發(fā)也不正常，業(yè)務自己需要完善。QPS ?15000/s ??? 。 下面是 業(yè)務改版后的趨勢圖：