在做db基準測試的時候，qps,tps是衡量數據庫性能的關鍵指標。QPS（Queryper second）每秒查詢量,TPS（Transactionper second）每秒事務量。

• QPS：Queries / Seconds

Queries 是系統狀態值--總查詢次數

• TPS：(Com_commit + Com_rollback) / Seconds

mysql中沒有直接的事務計數器，需要通過事務提交數和事務回滾數來計算。這是Mysql的兩個重要性能指標，需要經常查看，和Mysql基準測試的結果對比，如果值過高，就要盡快處理了。

生產一MySQL數據庫日常平均QPS為2000左右，峰值3500，但業務新需求上線后，其QPS竟高達2.2萬，是以前平均值的11倍，此種情況過于異常。詢問業務側是否上線大業務處理場景，業務側反饋無，業務系統和以前幾乎一樣。

既然業務側不能提供有用的信息，那只能從數據庫側著手分析了。先從數據庫監控平臺查看：

1、近1小時qps曲線

近一小時內，數據庫QPS都在2.2萬以上

2、近1小時數據庫各類操作曲線

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

3、分析general log

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

打開數據庫的generallog，收集了7分鐘的信息，并進行分析，分析結果如下：

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

4、解決方案

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

引起這種現象的僅有業務系統代碼，我懷疑業務代碼，否存在以下情況：

• 運行大量空事物

• 引用的架構中隱藏對事務的操作，但該操作不合理

把該現象及分析結果告之業務側，讓其查看業務代碼，最終業務側反饋，他們使用的一個架構中對事務的處理存在bug，并在下次業務發布時修復該bug。修復該bug的業務版本上線后，在數據庫側持續觀察兩天，再無出現該問題，即該問題也圓滿解決。

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