MySQL 性能指标之 QPS、TPS、IOPS
本文主要介绍MySQL数据库，或者说所有数据库的三个关键性能指标：
- QPS：Queries Per Second，每秒处理的查询次数，QPS = 总查询次数 / 统计时间(秒)
- TPS：Transcations Per Second，每秒处理的事务个数，QPS = 总事务个数 / 统计时间(秒)
- IOPS：每秒磁盘进行的I/O读写操作次数，对于随机读写频繁的应用（如OLTP），IOPS是关键衡量指标
个人理解：一次页面的请求，可能产生多次对mysql的请求，对于这些请求都可以计入qps，从而一个Transcation会产生多个Query
QPS的定义和计算方法
- 以下是三种常见的 QPS 计算方式，推荐采用 方法2
| 计算方法 | 计算规则 | 备注 |
|---|---|---|
| 方法1 | QPS = DQL(select)-per-second | 把 Query 理解为查询(Select)不合理，若从库只有写没有读，即 QPS = 0 显然不合理 |
| 方法2 | QPS = Queries-per-second | show global status like 'Queries'; 推荐此统计方法 |
| 方法3 | QPS = Questions-per-second | Questions 不统计存储过程和预准备语句等，亦不合理 |
注：QPS 中的 Query，不应该只是 Select 查询操作，而是 SQL = DQL + DML + DDL + DCL
- 官方文档对 Queries 的解释：
show global status like 'Queries';
Queries
The number of statements executed by the server. This variable includes statements executed within stored programs, unlike the Questions variable. It does not count COM_PING or COM_STATISTICS commands.
注：与 Questions 计数不同，此变量包括了存储过程中执行的语句。它不计数 COM_PING 或 COM_STATISTICS 命令
- 官方文档对 Questions 的解释：
show global status like 'Questions';
Questions
The number of statements executed by the server. This includes only statements sent to the server by clients and not statements executed within stored programs, unlike the Queries variable. This variable does not count COM_PING, COM_STATISTICS, COM_STMT_PREPARE,COM_STMT_CLOSE, or COM_STMT_RESET commands
注：与 Queries 计数不同，它不仅不统计存储过程，也不统计 COM_PING, COM_STATISTICS, COM_STMT_PREPARE,COM_STMT_CLOSE 或 COM_STMT_RESET 等命令
- Queries 计数和 Questions 计数的区别如下（Queries统计的更多）：
| 指标 | Queries 计数 | Questions 计数 | 备注 |
|---|---|---|---|
| 存储过程 | 包含 | 不包含 | 内部存储语句，非文本SQL交互 |
| COM_STMT_PREPARE | 包含 | 不包含 | 预准备语句，非文本SQL交互 |
| COM_STMT_CLOSE | 包含 | 不包含 | 预准备语句，非文本SQL交互 |
| COM_STMT_RESET | 包含 | 不包含 | 预准备语句，非文本SQL交互 |
如何计算 QPS
- 思路：在2个取样点采集 Queries，然后 QPS = Queries 数值差值 / 秒数
- 实测：如下示例在 10 秒内，Queries 从 11222618479 增长到 11222664496，那么这10秒的 QPS = ( 11222664496 - 11222618479 ) / 10 = 4601.7
#.开始采样 2021-04-15 19:05:05
mysql> show global status like 'Que%';
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| Queries | 11222618479 | #.建议用这个
| Questions | 5839113474 | #.不包括存储过程及预准备语句,计数少了许多
+---------------+-------------+
#.结束采样 2021-04-15 19:05:15
mysql> show global status like 'Que%';
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| Queries | 11222664496 |
| Questions | 5839220932 |
+---------------+-------------+
- 实测：2025年某游戏装备交易平台的一台阿里云RDS（104核-384GB）QPS峰值10w、TPS峰值3000
TPS 的定义和计算方法
- TPS的含义为每秒的事务数，因为MySQL只有 Innodb 才支持事务，讨论 MyISAM 引擎的TPS就没意义了
- 以下是三种常见的 TPS 计算方式，推荐 方法3
| 计算方法 | 计算规则 | 备注 |
|---|---|---|
| 方法1 | 计算增删改查总和 | 鉴于一个事务里可以跑多个SQL，则法违反了定义，不合理 |
| 方法2 | 计算 Com_commit、Com_rollback 总和 | 若不主动执行commit，则Com_commit为0，亦不可理 |
| 方法3 | 计算 Gtid 增长值 | MySQL 5.6 开始支持GTID，GTID既唯一又顺序递增，此法应该是最准确 |
- 方法1：从
show global status;获取 (Com_insert + Com_delete + Com_update + Com_select + Com_delete_multi + Com_update_multi)的增长值 - 方法2：MySQL 默认设置了自动提交的（参数autocommit=1），即不显示 commit亦可自动提交事务。所以会有一个很尬尴的现象，因为主库因为不主动执行commit，所以Com_commit为0，而 binlog 是会自动补 commit 语句的，复制到从库时，从库回放 SQL 会带 commit，那么从库 Com_commit 则不为0，反而从库的 TPS 是真实的
- 方法3：GTID 保证了所有计数都是事务的，有人说利用 GTID 增量计算 TPS 没有包含 select 类型的事务，我觉得 GTID 没有给 select only 的事务一个 GTID 编号，也就是官方根本没有打算把这类查询的事务认为是事务，所以 GTID 本身确实是一种狭义的事务的概念，所以此方法计算出来的 TPS 也是一种狭义的 TPS，如果您关注业务的读，则建议看 QPS，如果您关注业务的写入，那就看 TPS。
如何计算 TPS
- 思路：在2个取样点采集 GTID 数值，然后 TPS = GTID 数值差值 / 秒数
- 实测：如下示例在 10 秒内，Executed_Gtid_Set 增长 7000，那么这10秒的 TPS = ( 1086313698 - 1086306698 ) / 10 = 700
#.开始采样 2021-04-15 19:05:05
mysql> show master status \G;
*************************** 1. row ***************************
File: mysql-bin.001709
Position: 687799580
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 522b6a42-d4c0-11eb-835a-00163e11f119:1-1086306698
#.结束采样 2021-04-15 19:05:15
mysql> show master status \G;
*************************** 1. row ***************************
File: mysql-bin.001709
Position: 687815236
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 522b6a42-d4c0-11eb-835a-00163e11f119:1-1086313698