QPS和TPS是单位时间内的增量速率，必须通过两次SHOW GLOBAL STATUS采样差值除以时间间隔计算；单次查询仅得累计值，无法反映实时负载，用Uptime作分母得到的是历史平均值而非当前波动值。
直接用 SHOW GLOBAL STATUS 查两次差值是最可靠、零依赖的 QPS/TPS 计算方式，但必须控制采样逻辑，否则结果完全失真。
为什么不能只查一次 SHOW GLOBAL STATUS 就算 QPS/TPS
QPS 和 TPS 都是速率指标，本质是「单位时间内的增量」。MySQL 的 Questions、Com_commit、Com_rollback 全是累计值，单次读取只能告诉你“从启动到现在一共多少”，和“每秒多少”毫无关系。
- 误用单次值会导致：数值越大，算出的 QPS/TPS 越高，完全无法反映实时负载
- 有人用
Uptime当分母（比如Questions / Uptime），这算的是“平均历史 QPS”，不是当前波动值，对容量评估或告警毫无意义 - 真正要监控的，是最近 1 秒、5 秒、10 秒窗口内的实际变化量
怎么用 SHOW GLOBAL STATUS 正确采样差值
核心就两步：记录初始值 → 等待固定时间 → 再查一次 → 做差除以时间。关键在“怎么取值”和“取哪些值”。
- QPS 推荐用
Questions：它统计所有语句（SELECT、INSERT、SET、SHOW等），比只加Com_select+Com_insert+...更全面且稳定 - TPS 必须用
Com_commit + Com_rollback：这是 MySQL 官方定义的事务结束动作计数器；Handler_commit不可用，它受内部 XA、隐式提交干扰大 - 采样时间建议 1–5 秒：太短（如 0.1 秒）噪声大；太长（如 30 秒）无法捕捉突发抖动
- 两次查询之间不要混入其他管理命令（如
SHOW PROCESSLIST），避免污染Questions计数
容易被忽略的 autocommit 干扰问题
当 autocommit=1（默认），每个 INSERT/UPDATE/DELETE 都会触发一次 Com_commit，所以 TPS 数值会远高于业务层理解的“显式事务数”。这不是错误，而是事实。
- 如果你要区分“用户发起的事务”和“自动提交的 DML”，不能靠
Com_commit，得切到performance_schema.transaction_instances查STATE = 'COMMITTED'并过滤EXTERNAL_USER - 但日常负载监控不需要这么细——
Com_commit + Com_rollback反映的是 InnoDB 实际承受的事务提交压力，这才是 DBA 关心的 TPS - 别用
INNODB_TRX表的COUNT(*)推 TPS：它只显示“当前未提交事务数”，和“每秒完成多少”完全无关，还可能因 metadata lock 拖慢采集
一行命令快速盯屏验证（适合终端临时看）
用 mysqladmin 自带的 --relative 模式最省事，它内部就是帮你做了差值计算：
mysqladmin -uroot -p -S /tmp/mysql.sock extended-status -r -i1 | grep -E "(Questions|Com_commit|Com_rollback)"
注意：-r 表示启用相对模式（自动做差），-i1 是每秒刷新。输出中第 4 列就是该秒的增量值。
- 第一行是无效的（没前值可减），从第二行开始才是真实 QPS/TPS
- 如果看到
Questions增量长期为 0，但应用有流量，检查是否用了连接池复用连接、SQL 被缓存或走从库读 - 若
Com_commit增量远大于Com_insert+Com_update+Com_delete总和，说明存在大量 autocommit=1 的单语句事务，属正常
真正难的不是算公式，而是确保两次采样之间没有干扰、时间间隔准确、指标含义不混淆。尤其在高并发写入场景下，哪怕 0.2 秒的脚本执行延迟，都会让 1 秒 TPS 出现 20% 误差。所以别图省事用 Uptime 代替实测时间差，也别把 Questions 和 Queries 当成一回事——它们在部分 MySQL 版本里统计口径并不完全一致。
