tps必须用com_commit与com_rollback两次采样差值除以真实uptime时间差，不可仅用com_commit或sleep间隔；因rollback同样消耗资源且autocommit下dml也计入com_commit，漏掉com_rollback会严重低估事务压力。
直接结论：TPS 必须用 Com_commit 和 Com_rollback 两次采样差值除以真实时间差（不是 sleep 时间），否则数值失真；只看 Com_commit 会严重低估真实事务压力。
为什么不能只查 Com_commit 就算 TPS
很多人误以为“提交才算事务”，于是只监控 Com_commit。但 MySQL 的事务结束动作包含两类：COMMIT 和 ROLLBACK，两者都消耗引擎资源、触发日志刷盘、影响锁释放节奏。尤其在异常频发或重试逻辑多的业务中，Com_rollback 可能占到总事务量的 15%–30%。漏掉它，等于把半边负载当空气。
更关键的是：autocommit=1 时，每条 INSERT/UPDATE/DELETE 都会触发一次 Com_commit；DDL（如 CREATE TABLE）也会隐式提交。所以 Com_commit 增量高 ≠ 业务层显式事务多，而是反映实际写入压力——这恰恰是 DBA 最该盯住的部分。
-
Com_commit单独使用，会忽略回滚开销和 autocommit DML 的真实事务语义 -
Handler_commit不可靠：它统计存储引擎层提交次数，受 XA、内部隐式提交干扰，波动大 -
INNODB_TRX表完全不能用来算 TPS：它只存“还没提交”的事务，是并发数，不是完成率
怎么用 mysqladmin 实时滚动看 TPS
运维现场最常用、零依赖的方式，适合快速判断是否突发抖动或持续压满：
mysqladmin -uroot -p -S /var/lib/mysql/mysql.sock extended-status -r -i1 | awk '/Com_commit|Com_rollback/ {print $2,$4}'
其中 -r 表示自动做差值，-i1 是每秒刷新。输出类似：
Com_commit 1245678 Com_rollback 98765
注意：这个命令默认用 Uptime 差值作为时间分母，比脚本里 sleep 1 更准——因为 Uptime 是 MySQL 内部单调递增的秒数，不受网络延迟、shell 调度影响。
- 如果看到
Com_rollback突然跳升，大概率是应用层重试失败或事务超时集中触发 -
Com_commit和Com_rollback同步飙升，说明写入密集且错误率未明显上升 - 该命令不暴露密码：建议用
~/.my.cnf配置凭据，避免命令行泄露
用 performance_schema 抓真实事务生命周期（MySQL 5.6+）
当需要区分“哪些事务慢”“是否卡在锁上”或排除 autocommit 干扰时，performance_schema 是唯一干净来源。核心是 transaction_instances 表：
SELECT COUNT(*) FROM performance_schema.transaction_instances WHERE STATE = 'COMMITTED' AND TIMER_END > (unix_timestamp() - 1) * 1000000000;
注意：transaction_instances 默认只保留约 10 秒的已完成事务记录，必须高频采集（建议 ≤ 2 秒间隔），否则漏数。
- 启用前确认：
setup_consumers中transactions和events_transactions_current都为ENABLED -
setup_instruments中transaction对应行也要开启，否则表为空 - 开启后有 3%–5% 性能开销，写入峰值超 5000 TPS 的实例需实测评估
别用 Uptime 当分母直接除（常见坑）
网上有些脚本写成 TPS = (Com_commit + Com_rollback) / Uptime，这是错的。Uptime 是 MySQL 启动以来的总秒数，不是采样窗口长度。正确做法是：
- 第一次查：
SHOW GLOBAL STATUS WHERE Variable_name IN ('Com_commit','Com_rollback','Uptime'); - 等 N 秒（比如 5 秒），再查一次
- 用两次
Uptime差值当分母，不是用当前Uptime值
否则你会得到一个越来越小的“TPS”，而且数值毫无意义——它其实是累计事务数除以运行总时长，相当于“平均历史吞吐”，不是“当前负载”。
真正难的不是计算公式，而是理解：TPS 是瞬时压力快照，不是统计平均值；它要匹配业务请求节奏，而不是数据库存活时间。
