知识篇 | 数据库性能指标之QPS和TPS

数据库的两个指标的重要性：理解QPS和TPS是衡量数据库性能的重要参照指标项。

两个指标看似很简单，但深入理解它们的含义、区别、关联以及如何运用，对于数据库设计、优化和容量规划至关重要。本文将系统学习一下：

一、核心概念与定义

1. QPS (Queries Per Second) - 每秒查询次数

定义：数据库服务器每秒能够处理的查询请求的数量。“查询” (Query) 的含义：

1)最狭义：仅指SELECT 语句（读操作）。

2)较常用：指所有类型的SQL语句，包括 SELECT、INSERT、UPDATE、DELETE、SHOW 等。这更接近数据库实际处理的“请求”数。

3)注意：在监控工具（如MySQL的SHOW GLOBAL STATUS中的Queries计数器）中，通常统计的是所有类型的SQL语句。

关注点：处理请求的速率。它反映了数据库处理SQL语句（无论读写）的吞吐量能力。

本质：衡量数据库服务请求的能力。

2. TPS (Transactions Per Second) - 每秒事务数

定义：数据库服务器每秒能够成功完成的事务的数量。“事务” (Transaction) 的含义：

1)指一个逻辑工作单元，由一个或多个SQL语句组成。

2)事务的核心特性是ACID：

a.A (Atomicity) 原子性： 事务内的所有操作要么全部成功，要么全部失败回滚。

b.C (Consistency) 一致性： 事务执行前后，数据库从一个一致状态转换到另一个一致状态。

c.I (Isolation) 隔离性： 并发执行的事务互不干扰。

d.D (Durability) 持久性： 一旦事务提交，其结果就是永久性的。

3)事务以BEGIN / START TRANSACTION 开始，以 COMMIT（提交，使更改永久生效）或 ROLLBACK（回滚，撤销所有更改）结束。

本质：衡量数据库完成有效业务逻辑的能力；该指标反映了数据库处理保证数据一致性的操作单元的能力。

二、关键区别与关联

1. 核心区别：

粒度不同：QPS 关注单个SQL语句的处理速率；TPS 关注包含一个或多个SQL语句的业务逻辑单元（事务）的完成速率。标准不同：

1)QPS：通常指数据库接收并尝试处理的查询数量（即使最终执行失败，这个请求也可能被计入QPS）。

2)TPS：特指成功提交的事务数量。只有 COMMIT 成功的事务才计入TPS。回滚(ROLLBACK)或失败的事务不计入有效TPS。

关注维度不同：

3)QPS 更偏向于技术层面的吞吐量（处理了多少个请求）。

4)TPS 更偏向于业务层面的吞吐量（完成了多少个有效业务操作）。例如，一个“下单”事务可能包含插入订单、扣减库存、记录日志等多个SQL操作，TPS统计的是每秒成功下单的次数。

2. TPS和QPS的关联关系：

一个事务包含多个查询：这是最常见的情况。例如：

一个转账事务：UPDATE 账户A扣款 -> UPDATE 账户B加款 -> COMMIT。这个事务包含 2个写操作(Query)，但只算作 1个事务(TPS)。

一个复杂的报表查询：可能是一个包含多个JOIN的 SELECT 语句。如果它在一个显式事务中执行（虽然读事务通常不需要显式提交，但概念上仍是一个工作单元），它可能算作 1个事务(TPS) 包含 1个复杂查询(QPS)。

简单事务可能等于查询： 一个只包含单个SELECT 或 UPDATE 的AUTOCOMMIT事务（默认模式，每条语句自动提交），可以近似认为 1 QPS ≈ 1 TPS。但这并非严格相等，因为事务管理（BEGIN/COMMIT）本身也有开销。

TPS ≤ QPS： 在大多数包含多个查询的事务场景下，TPS 的值通常会小于或等于 QPS。因为完成一个事务需要处理多个查询。TPS = QPS / (平均每个事务包含的查询数) 是一个简化的理解公式（忽略了事务控制语句的开销）。

相互影响： 高QPS不一定意味着高TPS（可能有很多小查询或只读操作）。高TPS通常意味着较高的QPS（因为事务包含多个查询）。优化QPS（如改进单条SQL效率）可能提升TPS；优化TPS（如减少事务锁竞争）也可能间接影响QPS。

三、常用的几种数据库的测量与监控

1. 数据库内置状态变量/性能视图：

MySQL:

1)SHOW GLOBAL STATUS LIKE 'Queries%';： Queries 计数器显示服务器启动以来处理的查询总数（通常包含所有语句类型）。计算QPS需要取两次快照的差值除以时间间隔。

2)SHOW GLOBAL STATUS LIKE 'Com_commit%';： Com_commit 计数器显示提交的事务总数。

3)SHOW GLOBAL STATUS LIKE 'Com_rollback%';： Com_rollback 计数器显示回滚的事务总数。

            TPS ≈ (Com_commit + Com_rollback) / 时间间隔？ 严格来说，只有Com_commit代表成功的事务。Com_rollback代表显式回滚或系统回滚的事务，通常不计入有效TPS（业务失败）。更严谨的TPS计算通常直接基于业务成功提交点来统计。

            InnoDB 引擎指标： SHOW ENGINE INNODB STATUS; 输出中的TRANSACTIONS 部分也提供事务信息。

PostgreSQL:

1)SELECT * FROM pg_stat_database;： xact_commit (已提交事务数) 和 xact_rollback (已回滚事务数) 是核心指标。tup_fetched/tup_returned (行读取) 和 tup_inserted/tup_updated/tup_deleted (行修改) 可以辅助分析查询负载。计算同样需要差值。

Oracle:

1)V$SYSSTAT 视图：查找 user commits (用户提交的事务数), user rollbacks (用户回滚的事务数), execute count (执行次数，接近QPS概念) 等统计信息。

SQL Server:

1)sys.dm_os_performance_counters DMV：查找 Transactions/sec (每秒事务数), Batch Requests/sec (每秒批处理请求数，接近QPS概念) 等计数器。

2. 专业监控工具：

Prometheus + Grafana: 通过 exporter (如 mysqld_exporter, postgres_exporter) 抓取数据库指标，在Grafana中绘制QPS、TPS等实时和历史趋势图。

Datadog, New Relic, Dynatrace: 商业APM工具，提供开箱即用的数据库性能仪表盘，包括QPS、TPS、延迟、错误率等。

Percona Monitoring and Management (PMM): 开源MySQL/MongoDB/PostgreSQL监控方案，提供丰富的性能指标视图。

阿里云/腾讯云/AWS CloudWatch RDS 监控： 云数据库服务通常在其控制台提供QPS、TPS等核心性能指标监控。

四、典型值范围与影响因素

划重点：没有“标准值”： QPS和TPS的“好”或“坏”完全取决于具体业务场景、硬件配置、数据库架构和优化水平。

一个优化良好的小型博客可能在低端服务器上达到几百QPS，而大型电商平台在高端分布式数据库上可能需要处理几十万甚至上百万的TPS。

关键影响因素：

硬件资源：CPU速度与核心数、内存容量与速度、磁盘IOPS/吞吐量（特别是SSD vs HDD）、网络带宽与延迟。

数据库配置：连接池大小、缓冲池/共享缓冲大小、日志写入策略、并发控制机制（锁、MVCC）配置。

Schema设计： 表结构、索引设计（缺失或不合理的索引是性能杀手）、数据类型选择。

查询/事务设计：

SQL语句效率：是否存在全表扫描、复杂JOIN、低效子查询？是否使用了绑定变量？

事务设计：事务范围是否过大（导致锁持有时间长）？是否包含不必要的操作？是否合理使用隔离级别？

并发负载：高并发下锁竞争、资源争用（CPU、IO）会显著降低QPS和TPS。

数据量与分布：表大小、数据冷热分布、数据倾斜。

网络延迟：对于分布式数据库或应用服务器与数据库分离部署的场景。

五、重要应用场景

1. 性能基准测试 (Benchmarking)： 使用工具如 sysbench, TPC-C, TPC-H, HammerDB 等模拟负载，测量不同硬件、配置或数据库版本下的QPS/TPS极限值，作为选型和优化的依据。

2. 容量规划 (Capacity Planning)： 根据当前或预期的业务量（如预计促销期间订单量），估算所需的QPS/TPS峰值。结合基准测试结果，判断现有或规划中的数据库服务器/集群是否能支撑未来负载。是扩容硬件、优化软件还是进行分库分表的决策基础。

3. 性能监控与告警： 实时监控生产环境的QPS/TPS及其趋势。设置告警阈值（如TPS低于预期值80%持续5分钟，或QPS异常陡增），及时发现性能瓶颈、流量突增或潜在故障。

4. 性能瓶颈分析： 当系统变慢时，结合QPS/TPS、响应时间( Latency )、CPU利用率、IO等待、锁等待等指标，定位瓶颈源头：

    1)QPS高但TPS低？可能事务过大或锁竞争严重。

    2)TPS下降但QPS没变？可能事务提交变慢（如日志写入瓶颈）。

    3)QPS/TPS都低且CPU/IO空闲？可能应用连接数不足或网络问题。

    4)QPS/TPS高且CPU/IO饱和？需要优化查询/事务或扩容。

5. 优化效果验证： 在优化了SQL语句、添加了索引、调整了配置参数后，对比优化前后的QPS/TPS提升，量化优化成果。

六、总结与最佳实践

1. 明确概念： 牢记QPS是“查询/请求速率”，TPS是“成功事务速率”。理解事务(Transaction)的边界和ACID特性是理解TPS的关键。

2. 区分场景：

    1）读密集型场景(如资讯网站、报表系统)： QPS (尤其是SELECT QPS) 是核心指标。关注缓存命中率、查询效率、主从复制延迟。

    2）写密集型/交易型场景 (如电商下单、支付系统)： TPS 是核心生命线。关注事务设计、锁竞争、写缓冲、日志写入性能、数据一致性保证。

3. 结合监控： 不要孤立地看QPS或TPS。必须结合响应时间(Latency/P99)、资源利用率(CPU, Memory, Disk IO, Network)、错误率(Errors)、并发连接数(Threads Connected)等指标一起分析才能全面判断数据库健康状况和性能瓶颈。低延迟下的高QPS/TPS才是真的高性能。

4. 关注趋势与基线： 建立性能基线（正常运行时的典型值）。关注指标的变化趋势（如缓慢增长、周期性波动、突然尖峰或下跌）比绝对值更重要。

5. 优化根源： 提升QPS/TPS的根本在于：

优化SQL与索引： 这是投入产出比最高的手段。

合理设计事务：避免长事务，减小事务粒度（在业务允许范围内）。

优化架构：读写分离、缓存(Redis/Memcached)、分库分表。

调整配置：根据负载调整内存分配、连接池、并发参数。

升级硬件：当软件优化达到瓶颈时。

6. 理解业务： 最终，QPS/TPS 是为业务服务的。了解每个事务对应的业务含义（如“下单TPS”、“支付TPS”）对于设定合理的性能目标和进行容量规划至关重要。

文章至此。