3. 数据库服务器性能指标体系

在数据库服务器调优中，性能指标不是一组孤立的数字，而是一套相互约束、彼此解释的观测体系。同一台基于Intel Xeon的数据库服务器，TPS高但响应时间抖动大，说明事务提交路径可能存在锁竞争或日志刷盘瓶颈；QPS高但IPC低，说明CPU大量时间消耗在等待而非执行；吞吐量看似饱和但内存带宽已接近上限，则继续加并发只会让延迟进一步恶化。因此，理解每个指标的定义、量纲、观测位置以及它们之间的因果关系，是建立性能基线的第一步。

一、核心指标的定义与量纲

TPS（Transactions Per Second）指每秒成功提交的事务数，强调“事务完整性”，通常以BEGIN…COMMIT为一次计数单位，适用于OLTP场景。QPS（Queries Per Second）指每秒执行的查询语句数，一条事务可能包含多条SQL，因此QPS通常大于TPS。两者都必须与成功率、错误率一起看，否则重试风暴会虚高计数。

响应时间（Response Time / Latency）是单次请求从发出到收到完整结果的时间，常用P50、P95、P99分位表达。平均值会被长尾掩盖，数据库调优更关注P99。吞吐量（Throughput）是单位时间内系统处理的数据量或请求量，可用MB/s、行/s或请求/s表示，它与响应时间在未饱和区近似满足“吞吐量≈并发度/响应时间”的Little定律关系。

并发度（Concurrency）指同时处于处理中的请求数，包括活跃连接数、活跃会话数与正在执行的线程数，不等同于连接池上限。CPU利用率反映Xeon物理核心的忙碌比例，需区分用户态、系统态、iowait与steal。IPC（Instructions Per Cycle）是每时钟周期退休指令数，IPC下降往往意味着缓存未命中、分支预测失败或内存等待增加。内存带宽指单位时间从内存读取/写入的数据量，Xeon多通道DDR5下可用STREAM类负载测量。I/O延迟指存储设备完成一次读写请求的耗时，需区分设备延迟与应用可见延迟。

二、指标之间的约束关系

这些指标并非独立。以Xeon平台为例，当并发度从64提升到256时，TPS可能先上升后持平，而P99响应时间持续上升。此时若观察到IPC从1.8降到1.1、内存带宽从60%升到92%，可以判断瓶颈已从CPU执行转向内存子系统。若iowait同步升高、I/O延迟P99从0.8ms升到6ms，则瓶颈在存储路径。调优的方向由此确定：前者需要优化NUMA绑定与数据局部性，后者需要检查日志盘与数据盘的队列深度。

另一个常见关系是CPU利用率与IPC的“双高”与“一高一低”。CPU利用率高且IPC高，说明计算密集且执行效率好；CPU利用率高但IPC低，说明核心在空转等待内存或锁，此时增加核心数收益有限。因此，基线中必须同时记录CPU利用率与IPC，不能只看利用率。

三、面向Xeon平台的基线采集实操

基线采集的核心原则是“负载可复现、时间可对齐、环境可追溯”。以下给出一个可参考的采集流程与参数示例，示例中的数值为教学假设，不代表真实实测结果。

# 1. 固定CPU频率策略，减少调频干扰
cpupower frequency-set -g performance

# 2. 采集CPU利用率与IPC（每5秒一次，共12次）
perf stat -a -e cycles,instructions,cache-misses \
  -I 5000 -- sleep 60

# 3. 采集内存带宽（需提前编译STREAM或使用pcm-memory）
pcm-memory.x 5 -silent

# 4. 采集I/O延迟与队列深度
iostat -xmt 5 | awk '{print $1,$NF,$14,$15}'

# 5. 数据库侧同步记录TPS/QPS/响应时间分位
# 以PostgreSQL为例，查询pg_stat_statements与pg_stat_database
SELECT datname, xact_commit, xact_rollback,
       blks_read, blks_hit, tup_returned
FROM pg_stat_database WHERE datname='benchdb';

采集时需注意三点。第一，预热阶段至少运行5分钟，让Xeon的LLC、分支预测器和数据库缓冲池进入稳定状态，预热数据不计入基线。第二，所有采集工具的时间戳要统一到同一时钟源，否则TPS峰值与IPC谷值可能错位，导致误判。第三，记录NUMA节点分布与中断亲和性，例如使用numactl --hardware和cat /proc/interrupts，因为跨NUMA访问会让内存带宽指标虚高而有效带宽下降。

四、基线对比与结果判读

建立基线后，每次调优变更都应做同负载复测。判读时按以下顺序进行：先看响应时间P99是否恶化，再看TPS是否提升，最后看IPC与内存带宽是否解释了变化原因。若TPS提升但P99恶化超过20%，通常认为该变更不适合生产；若TPS持平但IPC提升、CPU利用率下降，说明效率改善，可为后续扩容留出余量。

最后需要强调，指标采集本身会带来开销。perf全量采集在高并发下可能引入3%～8%的额外CPU消耗，pcm-memory也会占用少量核心。因此，基线采集应尽量在独立监控节点或低开销采样模式下进行，并在报告中注明采集工具与采样频率，确保对比结果具有可比性。