QPS和TPS需通过两次采样差值计算，不能直接用SHOW GLOBAL STATUS累计值；mysqladmin -r -i1配合extended-status可实时获取增量，脚本采集须自行记录时间戳而非依赖Uptime，且应避免运维干扰与短时抖动。
QPS 和 TPS 不是 MySQL 直接输出的实时值，必须靠两次采样差值计算——跳过这步直接看单次 SHOW GLOBAL STATUS 结果，得到的是累计值，毫无监控意义。
用 mysqladmin 实时滚动看 QPS/TPS 增量
适合终端盯屏、快速判断当前负载趋势，不需要写脚本：
-
mysqladmin -uroot -p -S /var/lib/mysql/mysql.sock extended-status -r -i1中的-r参数才是关键：它自动对连续两次输出做差值，-i1表示每秒刷新一次 - 输出里找
Queries（对应 QPS）、Com_commit和Com_rollback（两者和对应 TPS）所在行，它们的数值已经是“每秒增量”，不是累计值 - 注意：如果连接用的是 TCP（比如
-h 127.0.0.1 -P 3306），务必确认skip-networking没开启，否则会连不上；Unix socket 路径要和my.cnf里socket配置一致 - 别信第 6 列是 Queries ——这是旧版文档误传，新版
mysqladmin status输出列序不稳定，必须用extended-status+ 正则或awk提取字段名
Shell 脚本定时采集，避免 Uptime 误当时间差
很多人用 Uptime 当分母，但 Uptime 是 MySQL 启动至今的秒数，不是两次采集的真实间隔。脚本必须自己记录时间戳：
- 第一次执行
mysqladmin -s status，提取Queries和Uptime值（例如：Queries 125000、Uptime 86400） -
sleep 5，再执行一次，得到新值（Queries 125420、Uptime 86405） - QPS = (125420 − 125000) / (86405 − 86400) = 420 / 5 = 84；TPS 同理用
Com_commit和Com_rollback差值除以 5 - 密码不能写死在命令里，用
~/.my.cnf存凭证，且权限必须是600，否则mysqladmin会拒绝读取
为什么不用 Questions 替代 Queries？
Questions 不统计存储过程内部执行的语句，而 Queries 统计——如果你的应用大量使用存储过程，只看 Questions 会严重低估真实 QPS：
-
SHOW GLOBAL STATUS LIKE 'Queries'包含所有 SQL 语句（DML、DDL、DCL、DQL），也包括 SP 内部语句 -
SHOW GLOBAL STATUS LIKE 'Questions'只统计客户端直接发送的语句，SP 内部执行不计入 - 线上业务若用 SP 封装逻辑（比如订单创建流程），
Questions可能只有Queries的 1/3～1/2，误用会导致容量评估偏差 - TPS 严格依赖
Com_commit和Com_rollback，这两个变量只对事务引擎（InnoDB）有效，MyISAM 表的INSERT等操作不会增加它们
真正难的不是算公式，而是确保两次采样之间没有其他运维操作（如 flush logs、重启服务）干扰状态变量；另外，高并发下 Com_commit 可能被多个线程同时更新，短时间差（如 1 秒）内采样容易抖动——建议最小采样间隔设为 3 秒以上，尤其在 TPS > 500 的实例上。
