在做db基準(zhǔn)測試的時候，qps,tps是衡量數(shù)據(jù)庫性能的關(guān)鍵指標(biāo)。QPS（Queryper second）每秒查詢量,TPS（Transactionper second）每秒事務(wù)量。

• QPS：Queries / Seconds

Queries 是系統(tǒng)狀態(tài)值--總查詢次數(shù)

• TPS：(Com_commit + Com_rollback) / Seconds

mysql中沒有直接的事務(wù)計數(shù)器，需要通過事務(wù)提交數(shù)和事務(wù)回滾數(shù)來計算。這是Mysql的兩個重要性能指標(biāo)，需要經(jīng)常查看，和Mysql基準(zhǔn)測試的結(jié)果對比，如果值過高，就要盡快處理了。

生產(chǎn)一MySQL數(shù)據(jù)庫日常平均QPS為2000左右，峰值3500，但業(yè)務(wù)新需求上線后，其QPS竟高達(dá)2.2萬，是以前平均值的11倍，此種情況過于異常。詢問業(yè)務(wù)側(cè)是否上線大業(yè)務(wù)處理場景，業(yè)務(wù)側(cè)反饋無，業(yè)務(wù)系統(tǒng)和以前幾乎一樣。

既然業(yè)務(wù)側(cè)不能提供有用的信息，那只能從數(shù)據(jù)庫側(cè)著手分析了。先從數(shù)據(jù)庫監(jiān)控平臺查看：

1、近1小時qps曲線

近一小時內(nèi)，數(shù)據(jù)庫QPS都在2.2萬以上

2、近1小時數(shù)據(jù)庫各類操作曲線

從圖上可以看出，每秒對數(shù)據(jù)庫的set操作高達(dá)19547次，在QPS中占比高達(dá)99%。

3、分析general log

從監(jiān)控平臺僅能看到set操作占比最高，但卻無法知道具體是什么set操作，基于此種情況，只好打開數(shù)據(jù)庫的generallog，分析上圖中set操作具體是什么。

打開數(shù)據(jù)庫的generallog，收集了7分鐘的信息，并進(jìn)行分析，分析結(jié)果如下：

以上4種操作每秒執(zhí)行次數(shù)加起來就和數(shù)據(jù)庫的QPS差不多了，因些可以肯定就是這4種SET操作過于頻繁執(zhí)行，才引起數(shù)據(jù)庫的QPS過于異常。

4、解決方案

如果說以上4種set操作是為了對事務(wù)進(jìn)行有效控制，按一個事務(wù)內(nèi)包含一個SQL語句1:1的比例分配，那也應(yīng)該有相應(yīng)的select、update、delete、insert操作次數(shù)，但從實際的情況來看，每秒僅有291次insert、2次select操作，明顯與事務(wù)控制操作次數(shù)不符。

引起這種現(xiàn)象的僅有業(yè)務(wù)系統(tǒng)代碼，我懷疑業(yè)務(wù)代碼，否存在以下情況：

• 運行大量空事物

• 引用的架構(gòu)中隱藏對事務(wù)的操作，但該操作不合理

把該現(xiàn)象及分析結(jié)果告之業(yè)務(wù)側(cè)，讓其查看業(yè)務(wù)代碼，最終業(yè)務(wù)側(cè)反饋，他們使用的一個架構(gòu)中對事務(wù)的處理存在bug，并在下次業(yè)務(wù)發(fā)布時修復(fù)該bug。修復(fù)該bug的業(yè)務(wù)版本上線后，在數(shù)據(jù)庫側(cè)持續(xù)觀察兩天，再無出現(xiàn)該問題，即該問題也圓滿解決。

每秒數(shù)據(jù)庫執(zhí)行的查詢量即為QPS，它是衡量MySQL數(shù)據(jù)庫性能的一個主要指標(biāo)，但此查詢量不僅包括select、DML語句，還包括其它如set類的操作，如果set類操作占比比較大的話，它很可能會影響到數(shù)據(jù)庫的性能；因此，我們在MySQL的日常運維過程中，還是要常常分析下QPS中各類操作的占比情況，把過于異常的操作占比情況分析出來，防范于未然。