QPS和TPS计算必须基于两次SHOW GLOBAL STATUS采样的差值除以时间差；QPS推荐用Questions（不含存储过程和复制语句），TPS必须用Com_commit+Com_rollback；脚本中需sleep对齐时间、转整型相减、避免Uptime误导。
直接用 SHOW GLOBAL STATUS 查 QPS 和 TPS 的核心逻辑
MySQL 没有现成的 QPS 或 TPS 状态变量，所有计算都基于两个差值：状态值增量 ÷ 时间差。关键不是“查一次”，而是“查两次再相减”。SHOW GLOBAL STATUS 返回的是自实例启动以来的累计值，直接看单次结果毫无意义。
为什么用 Questions 而不是 Queries 计算 QPS 更稳妥
Questions 统计客户端发送的所有语句（SELECT、INSERT、UPDATE、DELETE、SET、SHOW 等），但不包含存储过程内执行的语句和复制线程产生的语句；Queries 则包含存储过程内的语句和复制语句，但日常业务监控中，它容易被误判为“真实业务查询量”。尤其在启用了 GTID 或主从延迟较大时，Queries 增量可能突然跳高，而 Questions 更贴近应用层实际请求量。
- 推荐默认用
Questions：更稳定，适合绝大多数 Web/APP 场景 - 仅当需要统计含存储过程调用的总执行量时，才切到
Queries - 注意：
Com_ping、Com_statistics、Com_stmt_prepare等不计入Questions，这是设计使然，不用额外过滤
TPS 必须用 Com_commit + Com_rollback，不能用 DML 类变量求和
严格来说，TPS = (Com_commit + Com_rollback) / 时间差 是唯一合规定义。有人用 Com_insert + Com_update + Com_delete 估算“写操作频次”，但这不等于事务数——MyISAM 表的 DML 不走事务，InnoDB 中一条 INSERT 可能属于一个跨多表的大事务，也可能自动提交为独立事务。只有 Com_commit 和 Com_rollback 明确对应事务生命周期的终点。
-
Com_commit计数显式COMMIT或 autocommit=1 下的隐式提交 -
Com_rollback计数显式ROLLBACK或异常中断触发的回滚 - 如果应用大量使用
autocommit=0且手动控制事务边界，这个值才真正反映事务吞吐能力 - 若值长期为 0，先检查
autocommit是否被全局关闭（SELECT @@global.autocommit;）
Shell 脚本里做差值时最容易漏掉的三个细节
手动写脚本采集时，90% 的误差来自时间对齐和变量类型处理，不是公式本身错。
- 两次
mysql -e "SHOW GLOBAL STATUS LIKE 'Questions'"之间必须用sleep N，不能靠命令执行耗时估算间隔——网络延迟、锁等待都会让实际间隔漂移 -
Value列是字符串，脚本中必须转为整型再相减（Bash 里用$(( ))，Python 里用int()），否则会拼接字符串导致结果为 0 或报错 - 别忽略
Uptime的干扰：有人用Questions / Uptime算“平均历史 QPS”，这只能看趋势，不能反映当前负载——比如刚重启的实例Uptime很小，一除就虚高
真正有效的实时 QPS/TPS，永远依赖两次采样间的精确时间差。哪怕只差 0.2 秒，对 100+ QPS 的实例，误差就能超过 20%。所以别图省事只查一次，也别信“平均值够用”——盯屏排查或告警触发时，差值才是唯一可信依据。
