在数据库性能监控领域，QPS（每秒查询数）和TPS（每秒事务数）是衡量数据库吞吐能力的关键指标。然而，许多MySQL新手常犯一个错误：试图直接查询这两个变量。实际上，MySQL并未提供名为“QPS”或“TPS”的现成状态变量。获取实时吞吐率的正确方法，核心在于“两次采样，差值计算”。
原因在于，SHOW GLOBAL STATUS命令返回的所有状态值，均为自MySQL实例启动以来的累计总量。直接读取单次结果（例如Questions=1,234,567）本身并无实际意义。要获得准确的实时性能指标，必须采集两个时间点的状态值，计算其增量，再除以精确的时间间隔。
使用 SHOW GLOBAL STATUS 计算 QPS 和 TPS 的核心原理
因此，监控的基石公式是：（状态值增量 ÷ 时间差）。任何跳过差值计算的简化方法，得出的都只能是长期平均值或具有误导性的数据，无法反映数据库的瞬时负载。
计算 QPS：为何选择 Questions 指标比 Queries 更可靠
明确了计算方法后，下一个关键点是选择正确的统计变量。计算MySQL的QPS时，通常面临Questions和Queries两个选择。它们之间存在重要区别：
Questions统计的是客户端发送的所有SQL语句数量，包括SELECT、INSERT、UPDATE、DELETE，以及SET、SHOW等命令。但其设计上会过滤掉存储过程内部执行的语句以及主从复制线程产生的语句。
Queries则统计范围更广，它包含了Questions的所有计数，同时增加了存储过程内部的调用以及复制相关的语句。虽然看似全面，但在业务监控场景下，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并手动控制事务时，它能真实反映数据库处理事务的吞吐能力。 - 监控提示：如果你发现TPS值长期为0或极低，应首先检查全局
autocommit设置（执行SELECT @@global.autocommit;），确认事务自动提交功能是否被关闭。
Shell 脚本实现差值计算时最易忽略的三个关键细节
理解了原理，但在编写监控脚本时，90%的误差并非源于公式错误，而是细节处理不当。以下三个常见陷阱，几乎每位开发者都可能遇到。
- 必须使用
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%的偏差。因此，在故障排查、性能调优或告警触发的关键时刻，基于时间窗口的精确差值计算是唯一可信赖的依据，切勿依赖长期平均值。
