在做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中各类操作的占比情况，把过于异常的操作占比情况分析出来，防范于未然。