获取MySQL数据库QPS和TPS指标的方法详解

在数据库性能监控中，QPS（每秒查询数）和TPS（每秒事务数）是两个核心的吞吐量指标。然而，直接在MySQL中查找这两个变量可能会令人失望，因为它并未提供现成的“QPS”或“TPS”状态值。这正是许多新手容易误解的地方：计算这两个指标的核心逻辑并非“查询一次”，而是“查询两次再相减”。

原因很简单，SHOW GLOBAL STATUS返回的所有数值，都是自数据库实例启动以来的累计总量。直接查看单次结果，例如Questions=1,234,567，这个数字本身并无意义。要获得真正的实时吞吐率，必须计算两个时间点之间状态值的增量，再除以精确的时间差。

使用 SHOW GLOBAL STATUS 计算 QPS 和 TPS 的核心逻辑

因此，整个监控的基石建立在差值计算上：状态值增量 ÷ 时间差。任何绕过此步骤的方法，得出的都只能是长期平均值或具有误导性的数据。

为何使用 Questions 而非 Queries 计算 QPS 更稳妥

确定了方法后，下一个问题是选择哪个变量。计算QPS时，通常有两个候选：Questions和Queries。这里存在一个关键区别：

Questions统计的是客户端发送的所有语句，包括SELECT、INSERT、UPDATE、DELETE，甚至SET、SHOW这类命令。但其设计上有一个“过滤”：不包含存储过程内部执行的语句，也不包含复制（Replication）线程产生的语句。

而Queries则包含了上述所有内容，既包含存储过程内的调用，也包含主从复制产生的语句。这听起来更全面，但问题恰恰出在这里。在日常业务监控中，我们更关心的是应用层发来的真实请求压力。如果启用了GTID，或者主从延迟较大时，Queries的增量可能会因复制线程的活动而突然升高，这反而会干扰我们对真实业务负载的判断。

• 默认推荐使用Questions：它更稳定，更能反映Web或APP应用直接施加的压力，适用于绝大多数场景。
• 仅在特定场景使用Queries：当你需要统计包含存储过程调用在内的所有语句执行总量时，才切换到它。
• 另外需要注意，像Com_ping（心跳检查）、Com_statistics这类内部命令本身就不计入Questions，这是预期行为，无需额外处理。

计算 TPS 必须使用 Com_commit + Com_rollback，而非 DML 变量求和

相比QPS，TPS的定义更严格，计算也更需讲究。严格来说，TPS = (Com_commit + Com_rollback) / 时间差，这是唯一符合事务定义的公式。

市场上有些取巧的做法，例如用Com_insert + Com_update + Com_delete的和来估算“写操作频率”，但这完全不等同于事务数。原因有二：首先，MyISAM引擎的DML操作根本不走事务流程；其次，在InnoDB中，一条INSERT语句可能属于一个包含多表操作的大事务，也可能在autocommit=1时自动提交为一个独立的小事务。直接用DML计数，完全无法区分这些情况。

只有Com_commit和Com_rollback这两个计数器，明确记录了事务生命周期的终点，无论是显式提交/回滚，还是自动提交触发的隐式操作。

• Com_commit：统计显式的COMMIT命令，以及在autocommit=1模式下每条语句执行后的隐式提交。
• Com_rollback：统计显式的ROLLBACK命令，以及事务因异常中断而触发的回滚。
• 这个值的意义在于：当你的应用大量使用autocommit=0并手动控制事务边界时，它才能真正反映数据库处理事务的吞吐能力。
• 如果你发现这个值长期为0，第一步应检查全局autocommit设置（SELECT @@global.autocommit;），看是否被意外关闭了。

Shell 脚本中进行差值计算时最易忽略的三个细节

理论清楚后，落实到脚本上，90%的误差往往不是公式错误，而是细节处理不当。以下三个细节，几乎每个DIY监控脚本的人都曾遇到过。

• 必须使用sleep对齐时间，不能依赖命令执行耗时：两次执行mysql -e “SHOW GLOBAL STATUS ...”之间，必须使用sleep N来强制间隔。网络延迟、服务器负载、甚至短暂的锁等待，都会让两次命令的实际间隔产生漂移，导致时间差不准确。
• 字符串必须转换为整型再计算：SHOW GLOBAL STATUS返回的Value列是字符串类型。在Bash脚本中直接相减会变成字符串拼接，结果通常是0或报错。务必使用$(( ))进行转换和计算（在Python中使用int()）。
• 警惕使用Uptime计算平均值：有人为图省事，使用Questions / Uptime来计算“历史平均QPS”。此方法只能反映一个非常长期、平滑的趋势，完全无法体现当前负载。例如数据库刚重启后，Uptime很小，相除会得到一个虚高且无参考价值的数值。

归根结底，要获取真正有效的实时QPS/TPS，必须依赖两次采样间的精确时间差。对于一台QPS超过100的实例，即使时间差仅误差0.2秒，计算结果的偏差也可能超过20%。因此，切勿相信“平均值够用”的说法，在紧盯屏幕排查问题或触发告警的关键时刻，基于时间窗口的差值计算，才是唯一可信的依据。