MySQL: 基准测试全流程指南：原理、工具(mysqlslap/sysbench)与实战演示

关注

原创最新推荐文章于 2026-08-24 14:24:05 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

sysbench压测mysql性能测试命令和报告 --mysql-db=tssysbench --tables=20 --table_size=1000000：这一串的意思，就是说在tssysbench这个库里，构造20个测试表，每个测试表里构造100万条测试数据，测试表的名字会是类似于sbtest1，sbtest2这个样子的。 --mysql-host=172.16.111.109 --mysql-port=13306 --mysql-user=root --mysql-password=123456：数据库的用户和密码等信息。阅读详情

MySQL数据库基准测试全面指南：原理、方法与实战

基准测试基础概念

1.1 ) 定义与核心目的
基准测试是通过系统化指标测量与评估软件性能的活动，旨在建立性能基线，量化硬件/软件变更对系统的影响。其核心价值在于：

建立性能基准线：量化优化前后的性能差异（如优化SQL索引后TPS的提升）。
模拟高压场景：通过逐步增加并发压力（如线程数），定位系统扩展瓶颈（如QPS峰值拐点）。
验证配置变更：测试硬件（SSD vs HDD）、软件（MySQL 5.7 vs 8.0）、存储引擎（InnoDB vs MyISAM）的性能差异。
投产前验证：确保新硬件配置符合预期性能（如新服务器上线前测试）。

1.2 ) 基准测试 vs 压力测试

基准测试：
- 数据来源：工具生成数据（如sysbench），与业务逻辑无关。
- 目标：测量特定组件的极限性能（如MySQL单查询并发吞吐量）。
- 特点：简化压力模型，聚焦硬件/配置的量化对比。
压力测试：
- 数据来源：真实业务数据（如用户购物车流程的完整SQL日志）。
- 目标：验证系统在真实业务场景下的稳定性（如高并发下单流程）。

关键区别：基准测试忽略业务逻辑，专注于组件性能对比；压力测试需模拟真实业务链路。

基准测试实施策略

目的：

建立性能基线：明确 MySQL 服务器当前性能状态，为优化效果提供参照。
模拟高负载：通过增加并发量，识别系统扩展瓶颈（如 QPS/TPS 拐点）。
验证配置变更：测试不同硬件（RAID 5 vs. RAID 10、SSD vs. HDD）、软件（MySQL 版本升级）或存储引擎（InnoDB vs. MyISAM）的性能影响。
硬件验收：在新硬件上线前验证配置正确性，避免性能未达预期。

2.1 ）测试方法分类

方法	优点	缺点	适用场景
整体系统测试	反映全链路性能（Web服务、缓存、DB）	耗时（需数日准备）、设计复杂	全局性能优化（如电商大促）
单独组件测试	快速验证（小时级）、简化设计	忽略组件间接口性能	MySQL参数调优、索引优化

关键性能指标：

吞吐量：
- QPS（Queries Per Second）：每秒查询量，衡量数据库处理能力。
- TPS（Transactions Per Second）：每秒事务量，关键于事务型系统。
响应时间：
包括平均响应时间、最小/最大响应时间及百分比响应时间（如 P90 响应时间）。重点关注 P90/P95（例如 90% 查询在 10ms 内完成），因其更能反映常态性能，排除锁竞争等异常干扰。
并发量：
指活跃工作线程数，而非总连接数。例如，Web 服务器显示万人在线，但数据库并发可能仅数十个。

2.2 ) 核心性能指标

指标	说明	计算方式
TPS	每秒处理的事务量（Transaction Per Second）	成功提交事务数 / 测试时间
QPS	每秒处理的查询量（Query Per Second）	执行查询总数 / 测试时间
响应时间	任务完成的整体时间（含多次操作）。重点关注P90/P95分位值（如90%请求≤10ms）	使用工具（如`sysbench`）统计百分位数
并发量	真正工作的并发线程数（非连接数）。例如：10万在线用户可能仅50个并发SQL操作	监控`MySQL`的`Threads_running`状态变量

误区纠正：

并发量 ≠ 在线用户数：1万在线用户可能仅产生20个活跃数据库线程。
最大响应时间无意义：受偶发锁等待影响；P90/P95分位值更具参考性。

基准测试实战步骤

测试流程

1 ）方案1

1.1 ) 规划与设计

测试范围：明确整体系统测试或单一组件（如MySQL）测试。
数据准备：
- 真实数据：使用生产环境备份库及Binlog日志回放（推荐pt-query-playback工具）。
- 工具生成：使用systbench生成测试数据（简化场景）。
执行策略：多次运行（≥3次），每次持续10分钟以上，取平均值。

1.2 ) 数据与脚本准备

系统监控脚本 (collect_stats.sh)：

#!/bin/bash 
INTERVAL=5  # 采集间隔（秒）
OUTDIR="/tmp/bench_stats"
MARKER="$OUTDIR/running"
mkdir -p $OUTDIR
touch $MARKER 
MYSQL="mysql -uroot -pXXX"  # 替换为实际账号 
 
while [ -f $MARKER ]; do 
  TIMESTAMP=$(date +%s)
  # 1. 系统负载 
  uptime >> "$OUTDIR/loadavg_$TIMESTAMP.log"
  # 2. MySQL全局状态 
  $MYSQL -e "SHOW GLOBAL STATUS" >> "$OUTDIR/global_status_$TIMESTAMP.log"
  # 3. InnoDB引擎状态
  $MYSQL -e "SHOW ENGINE INNODB STATUS\G" >> "$OUTDIR/innodb_status_$TIMESTAMP.log"
  # 4. 活跃线程
  $MYSQL -e "SHOW PROCESSLIST" >> "$OUTDIR/processlist_$TIMESTAMP.log"
  # 5. 扩展：CPU/磁盘监控（需安装sysstat）
  sar -u $INTERVAL 1 >> "$OUTDIR/cpu_$TIMESTAMP.log"
  iostat -dx $INTERVAL 1 >> "$OUTDIR/disk_$TIMESTAMP.log"
  sleep $INTERVAL
done

测试数据生成（示例）

CREATE DATABASE sbtest;
-- 使用sysbench生成100万行测试表
sysbench oltp_read_write.lua \
  --mysql-user=root \
  --mysql-password=XXX \
  --mysql-db=sbtest \
  --table-size=1000000 \
  --tables=10 \
  prepare

注：oltp_read_write.lua 是系统自带的，可以省略 .lua, 下同
与其他内置场景的关系
除 oltp_read_write 外，sysbench 还自带多个 OLTP 细分场景脚本，形成完整测试体系：

测试场景	功能描述	对应脚本文件
`oltp_read_write`	模拟读写混合事务（含查询、更新、插入、删除）	`oltp_read_write.lua`
`oltp_read_only`	仅包含读操作（如点查、范围查询）	`oltp_read_only.lua`
`oltp_write_only`	仅包含写操作（如更新索引列、插入、删除）	`oltp_write_only.lua`
`oltp_point_select`	单一主键查询性能测试	`oltp_point_select.lua`

这些脚本均基于公共模块 oltp_common.lua 实现，确保测试逻辑的一致性和可维护性

使用验证方法
可通过以下命令直接调用 oltp_read_write 场景，无需指定脚本路径，进一步证明其自带属性：

sysbench oltp_read_write --help  # 查看该场景的参数说明，验证是否存在

执行测试

工具：sysbench（常用）、tpcc-mysql（事务场景）。

命令示例：

sysbench oltp_read_write.lua \
  --threads=64 \              # 并发线程 
  --time=600 \                # 测试时长（秒）
  --mysql-db=sbtest \
  run

1.3 ) 结果分析脚本 (analyze_qps.sh)：

#!/bin/bash 
STATS_DIR="/tmp/bench_stats"
for file in $STATS_DIR/global_status_*.log; do
  # 提取相邻两次采集的QPS差值 
  prev_queries=$(grep "Queries" $prev_file | awk '{print $2}')
  curr_queries=$(grep "Queries" $file | awk '{print $2}')
  qps_diff=$(( (curr_queries - prev_queries) / INTERVAL ))
  # 输出时间戳与QPS 
  echo "$(date -d @${file##*_}) : $qps_diff QPS"
  prev_file=$file 
done

扩展指标：修改脚本可计算TPS（基于Com_commit）、并发线程数（Threads_running）

2 ）方案2

实施流程：
2.1. 规划与设计：

确定测试范围（全系统或单组件）。
选择测试数据：
- 真实生产数据（需完整备份及 SQL 日志回放）。
- 工具生成数据（简化操作，适合参数调优验证）。
设定测试时长与次数：多次运行取平均值，避免单次结果失真。

2.2. 数据与工具准备：

测试数据生成：使用工具（如 sysbench）创建数据集。

系统监控脚本：收集 CPU、磁盘 I/O、MySQL 状态（SHOW GLOBAL STATUS）等信息。
示例脚本（collect_metrics.sh）：

#!/bin/bash
INTERVAL=5  # 采集间隔(秒)
OUTPUT_DIR="/path/to/logs"
MARKER_FILE="$OUTPUT_DIR/running.marker"
MYSQL_PATH="/usr/bin/mysql"

touch $MARKER_FILE
while [ -f $MARKER_FILE ]; do
    TIMESTAMP=$(date +%s)
    # 收集系统负载 
    uptime >> "$OUTPUT_DIR/load_$TIMESTAMP.log"
    # 收集MySQL全局状态 
    $MYSQL_PATH -e "SHOW GLOBAL STATUS" >> "$OUTPUT_DIR/mysql_status_$TIMESTAMP.log"
    # 收集InnoDB状态 
    $MYSQL_PATH -e "SHOW ENGINE INNODB STATUS" >> "$OUTPUT_DIR/innodb_status_$TIMESTAMP.log"
    # 收集线程信息 
    $MYSQL_PATH -e "SHOW PROCESSLIST" >> "$OUTPUT_DIR/processlist_$TIMESTAMP.log"
    sleep $INTERVAL 
done

测试执行脚本：自动化多轮测试（例如循环增加并发线程数）。

2.3. 执行测试：

运行监控脚本与测试工具（如 sysbench）。

示例多线程测试命令：

sysbench oltp_read_write --threads=64 --time=600 run

2.4. 结果分析：

使用脚本计算 QPS/TPS 等指标。
分析脚本示例（analyze_qps.sh）：

#!/bin/bash 
LOG_DIR="/path/to/logs"
for file in $LOG_DIR/mysql_status_*.log; do
    # 提取时间间隔内的查询总量 
    START_QUERIES=$(grep "Queries" $file | awk '{print $2}')
    END_QUERIES=$(grep "Queries" $(ls -tr $LOG_DIR/mysql_status_*.log | tail -1) | awk '{print $2}')
    TIME_DIFF=5  # 与采集间隔一致 
    QPS=$(( (END_QUERIES - START_QUERIES) / TIME_DIFF ))
    echo "QPS: $QPS | Timestamp: $(echo $file | cut -d'_' -f3)"
done

可视化：通过工具（如 Grafana）展示吞吐量、响应时间趋势图。

关键注意事项：

数据真实性：避免使用生产数据子集，应采用完整备份，确保数据分布符合实际。
并发模拟：多用户场景必须使用多线程并发测试，单线程无法暴露锁竞争问题。
环境一致性：分布式系统（如主从架构）需在相同拓扑下测试，以包含中间件损耗。
查询多样性：避免重复相同查询导致缓存失真，应模拟真实查询混合模式。

3 ）方案3

3.1 规划与设计

数据选择原则：
优先使用生产环境完整备份及真实 SQL 日志（通过 general_log 捕获）。若仅验证参数调整，可采用工具生成数据。
测试周期：
单次测试无效，需多次运行取统计平均值（如 3 轮以上）。

3.2 数据与工具准备

系统监控脚本 (collect_system_stats.sh)：

#!/bin/bash
INTERVAL=5  # 采集间隔(秒)
OUTPUT_DIR="/opt/benchmark"
MARKER_FILE="${OUTPUT_DIR}/benchmark_running"
MYSQL_PATH="/usr/bin/mysql"

touch $MARKER_FILE 
while [ -f $MARKER_FILE ]; do 
  TIMESTAMP=$(date +%s)
  LOAD_AVG=$(uptime | awk -F'load average: ' '{print $2}')
  echo "$TIMESTAMP $LOAD_AVG" >> $OUTPUT_DIR/load_avg.log 
  
  $MYSQL_PATH -e "SHOW GLOBAL STATUS" >> $OUTPUT_DIR/mysql_global_${TIMESTAMP}.log
  $MYSQL_PATH -e "SHOW ENGINE INNODB STATUS" >> $OUTPUT_DIR/innodb_status_${TIMESTAMP}.log
  $MYSQL_PATH -e "SHOW PROCESSLIST" >> $OUTPUT_DIR/processlist_${TIMESTAMP}.log 
  
  sleep $INTERVAL 
done

3.3 执行测试

使用多线程工具（如 sysbench）并发施压

自动化脚本示例：

for i in {1..3}; do   # 运行3轮测试 
  ./collect_system_stats.sh &   # 启动监控 
  sysbench oltp_read_write --threads=64 --time=300 run
  pkill -f collect_system_stats  # 停止监控 
done

3.4 结果分析

QPS 计算脚本 (analyze_qps.py)：

import re
stats_files = sorted(glob.glob("/opt/benchmark/mysql_global_*.log"))

for i in range(1, len(stats_files)):
  with open(stats_files[i-1]) as f1, open(stats_files[i]) as f2:
    data1 = {k: int(v) for k,v in re.findall(r'(\w+)\s+(\d+)', f1.read())}
    data2 = {k: int(v) for k,v in re.findall(r'(\w+)\s+(\d+)', f2.read())}
    
    time_diff = file_timestamp(stats_files[i]) - file_timestamp(stats_files[i-1])
    queries_diff = data2['Queries'] - data1['Queries']
    qps = queries_diff / time_diff
    
    print(f"Interval {i}: QPS = {qps:.2f}")

关键注意事项

1 ) 数据真实性：

禁用数据子集抽样（如从1TB库抽1GB），需用完整生产数据副本。
避免单一查询重复执行（导致缓存命中失真），应使用真实查询序列。

2 ) 并发模型：

多用户场景必须启用多线程测试（单线程无法暴露锁竞争问题）。
分布式架构（如主从读写分离）需在同等架构下测试（中间件性能影响显著）。

3 ) 测试工具补充：

sysbench高级参数：自定义Lua脚本模拟复杂事务。
监控集成：Prometheus+Grafana实时可视化TPS/QPS趋势。

4 ) 常用工具：

sysbench：支持 CPU、内存、文件 I/O 及数据库（OLTP）测试。
mysqlslap：MySQL 内置基准测试工具，可模拟并发负载。

5 ) 原生 SQL 示例（测试数据生成）：

-- 创建测试表 
CREATE TABLE test_data (
    id INT AUTO_INCREMENT PRIMARY KEY,
    data VARCHAR(255),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
 
-- 插入随机数据（生成 100 万行）
INSERT INTO test_data (data)
SELECT SUBSTRING(MD5(RAND()), 1, 50) 
FROM information_schema.tables t1, information_schema.tables t2 
LIMIT 1000000;

原生 SQL 监控示例

-- 实时并发查询 
SELECT COUNT(*) AS active_threads 
FROM information_schema.PROCESSLIST 
WHERE COMMAND NOT IN ('Sleep');
 
-- 历史 QPS 计算
SELECT 
  (VARIABLE_VALUE - @prev_queries) / TIMESTAMPDIFF(SECOND, @prev_time, NOW()) AS qps,
  @prev_queries := VARIABLE_VALUE,
  @prev_time := NOW()
FROM performance_schema.global_status 
WHERE VARIABLE_NAME = 'Queries';

6 ) NestJS并发测试示例（模拟数据库访问）：

import { Injectable } from '@nestjs/common';
import { Pool } from 'pg'; // PostgreSQL驱动（替换为mysql2包兼容MySQL）
 
@Injectable()
export class BenchService {
  private pool: Pool;
 
  constructor() {
    this.pool = new Pool({ max: 100 }); // 最大连接数100
  }
 
  async runConcurrentQueries(threads: number, query: string) {
    const promises = [];
    for (let i = 0; i < threads; i++) {
      promises.push(this.pool.query(query));
    }
    return Promise.all(promises);
  }
}

性能监控端点：

import { Controller, Get } from '@nestjs/common';
import { MysqlService } from './mysql.service';
 
@Controller('metrics')
export class MetricsController {
  constructor(private readonly mysqlService: MysqlService) {}
 
  @Get('qps')
  async getQPS(): Promise<number> {
    const startQueries = await this.mysqlService.getGlobalStatus('Queries');
    await new Promise(resolve => setTimeout(resolve, 5000)); // 5秒间隔
    const endQueries = await this.mysqlService.getGlobalStatus('Queries');
    return (endQueries - startQueries) / 5;
  }
}

基准测试集成

// benchmark.service.ts 
import { Injectable } from '@nestjs/common';
import { InjectConnection } from '@nestjs/typeorm';
import { Connection } from 'typeorm';
import * as sysbench from 'sysbench-runner';
 
@Injectable()
export class BenchmarkService {
  constructor(@InjectConnection() private readonly connection: Connection) {}
 
  async runMySQLBenchmark(): Promise<BenchmarkResult> {
    // 1. 初始化测试数据
    await this.initializeTestData();
 
    // 2. 执行多轮测试
    const results = [];
    for (let i = 0; i < 3; i++) {
      const stats = await sysbench.run({
        test: 'oltp_read_write',
        threads: 64,
        time: 300,
        dbDriver: 'mysql',
        dbName: 'test_db'
      });
      results.push(stats);
    }
 
    // 3. 返回聚合结果
    return this.aggregateResults(results);
  }
 
  private async initializeTestData() {
    await this.connection.query(`
      CREATE TABLE IF NOT EXISTS benchmark_data (
        id INT PRIMARY KEY AUTO_INCREMENT,
        value FLOAT NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP 
      ) ENGINE=InnoDB;
      
      -- 插入百万级测试数据
      INSERT INTO benchmark_data (value) 
      SELECT RAND() * 1000 FROM INFORMATION_SCHEMA.COLUMNS c1, INFORMATION_SCHEMA.COLUMNS c2 
      LIMIT 1000000;
    `);
  }
}

通过以上结构化梳理，基准测试的核心概念、实施逻辑与实操细节得到连贯呈现，所有技术术语（如 InnoDB、QPS、TPS）已校正，冗余词汇已移除，原文意思完整保留。脚本与代码补充强化了实战指导性，SQL 与 NestJS 实现分离以满足不同场景需求。

常见误区总结

误区	正确方案
用在线用户数代替并发量	监控`Threads_running`统计真实工作线程
仅测试单次查询响应时间	多次运行取P90/P95分位值
新硬件未测试直接上线	基准测试验证配置（如RAID 5 vs RAID 10）
压力测试与基准测试混淆	明确目标：性能对比用基准，稳定性验证用压力

终极原则：基准测试结果必须可复现且直接服务于优化目标（如QPS提升20%）。

MySQL基准测试工具深度解析：mysqlslap与sysbench的技术实现与优化实践

内建工具 mysqlslap 详解

核心功能：MySQL 5.1+ 自带基准测试工具，无需独立安装，支持自动生成测试数据、模拟并发负载及多引擎测试。

1 ）核心参数与技术细节

参数	作用	技术要点
`--auto-generate-sql`	启用系统自动生成SQL脚本和数据	默认生成100行测试数据；通过`--number-char-cols`/`--number-int-cols`控制列数量
`--auto-generate-sql-add-autoincrement`	为表增加自增ID列	InnoDB必须启用：因InnoDB使用聚集索引，自增ID主键可优化写入性能
`--auto-generate-sql-write-number`	指定自动生成的数据行数（默认100）	增大该值可模拟大数据量场景
`--auto-generate-sql-execute-number`	自动测试中生成并执行的查询语句总数量（无默认值，需显式设置）	用于控制自动生成 SQL 查询语句执行次数的重要参数，适用于读取压力测试场景
`--concurrency`	指定并发连接数（如`10,20,30`）	允许多值逗号分割，工具依次执行不同并发测试
`--engine`	指定存储引擎（如`myisam,innodb`）	多引擎测试时按顺序执行，测试后自动清理数据（`--no-drop`可禁用清理）
`--only-print`	仅打印自动生成的SQL脚本而不执行测试	用于验证脚本逻辑，避免污染生产环境
`--query`	自定义SQL语句或存储过程路径	需确保SQL可重入；推荐使用存储过程实现随机查询
`--iterations`	测试重复次数	多次运行取平均值，减少单次测试波动影响
`--create-schema`	指定测试数据库名称	严禁使用生产库，避免测试数据与业务冲突

关键技术缺陷：

自动生成的InnoDB表未创建主键索引（即使启用自增ID），导致性能评估偏低。
仅支持数据库层级测试，无法覆盖CPU/内存/IO等系统级指标。

2 ）测试演示与结果分析

测试命令示例：

mysqlslap \  
  --concurrency=1,50,100,200 \  
  --iterations=3 \  
  --number-int-cols=5 \  
  --number-char-cols=5 \  
  --auto-generate-sql-add-autoincrement \  
  --engine=myisam,innodb \  
  --create-schema=sbtest \  
  --query="SELECT * FROM t1" \  
  --only-print  # 预览脚本（实际测试需移除）

性能对比结果：

并发数	引擎	平均耗时（秒）	结论
1	MyISAM	0.045	单线程下InnoDB更快
1	InnoDB	0.021
200	MyISAM	3.570	高并发下InnoDB优势显著
200	InnoDB	1.592

换个角度看

并发数	MyISAM平均耗时	InnoDB平均耗时
1	0.045秒	0.021秒
200	3.570秒	1.592秒

结论：InnoDB在高并发下性能优势显著

3 ）脚本审计模式

mysqlslap --auto-generate-sql --only-print

输出示例：

/* 自动生成的测试脚本 */
CREATE SCHEMA `perf_test`;
CREATE TABLE `t1`(
  id INT AUTO_INCREMENT PRIMARY KEY,  -- 强制自增主键
  col_int_1 INT,  -- 根据--number-int-cols生成
  col_char_1 VARCHAR(255) -- 根据--number-char-cols生成
);
INSERT INTO t1 VALUES(...); -- 随机数据填充 
SELECT ... FROM t1;         -- 混合操作语句 
DROP SCHEMA `perf_test`;    -- 默认清理

自动生成脚本关键逻辑（--only-print输出节选）：

CREATE SCHEMA IF NOT EXISTS `sbtest`;  
USE `sbtest`;  
 
-- 建表（MyISAM引擎示例）  
CREATE TABLE `t1` (  
  `id` INT NOT NULL AUTO_INCREMENT,  
  `col1` INT, `col2` VARCHAR(255), ... /* 5个INT和5个VARCHAR列 */,  
  PRIMARY KEY (`id`)  
) ENGINE=MyISAM;  
 
-- 插入测试数据（100行）  
INSERT INTO `t1` (`col1`, `col2`, ...) VALUES (RAND()*1000, UUID(), ...);  
... /* 重复100次 */  
 
-- 测试查询（混合读写）  
SELECT * FROM `t1` WHERE `col1`=RAND()*1000;  
UPDATE `t1` SET `col2`=UUID() WHERE `id`=RAND()*100;  
 
-- 清理数据  
DROP TABLE `t1`;  
DROP SCHEMA `sbtest`;

综合工具 sysbench 进阶指南

定位：多线程基准测试框架，支持数据库、CPU、内存、文件IO等全栈测试，通过Lua脚本定制场景。

1 ）与 mysqlslap 的核心差异

对比维度	mysqlslap	sysbench
测试范围	仅数据库	数据库 + 服务器硬件（CPU/内存/IO）
数据模型	自动生成简单表	支持OLTP复杂模型（事务、锁机制）
InnoDB优化	未优化主键索引	内置脚本正确使用自增ID主键
扩展性	有限	通过Lua脚本支持任意测试逻辑

工具定位

多维度测试：文件IO/CPU/内存/数据库综合评估
脚本化扩展：支持Lua语言定制测试场景
引擎深度支持：精准模拟InnoDB存储模式

注意：sysbench 1.0+版本弃用--test=oltp参数，需直接调用Lua脚本（如oltp_read_write.lua）。

2 ）编译安装指南（Linux环境）

步骤：

依赖安装（CentOS示例）
yum install autoconf libtool mysql-devel 
 
编译流程 
wget https://github.com/akopytov/sysbench/archive/refs/tags/1.0.20.zip
unzip 1.0.20.zip 
cd sysbench-1.0.20/
./autogen.sh 
./configure \
  --with-mysql-includes=/usr/local/mysql/include \ # MySQL头文件路径 
  --with-mysql-libs=/usr/local/mysql/lib          # MySQL库路径 
make && make install

验证安装  
sysbench --version

路径调整：若 MySQL 安装路径不同，需修改 --with-mysql-includes 和 --with-mysql-libs

3 ）关键测试类型与参数

参数	测试类型	用途
`--test=fileio`	文件IO性能	测试磁盘读写吞吐量
`--test=cpu`	CPU运算能力	计算素数检测速度
`--test=memory`	内存带宽	测量数据拷贝速率
`--test=threads`	线程调度	评估锁竞争性能
数据库专用参数
`--db-driver=mysql`	指定数据库驱动	必须启用
`--mysql-db=sbtest`	测试数据库名	非生产环境库
`--oltp-table-size`	测试表大小	建议 > 100万行
`--oltp-tables-count`	创建多表	模拟分库分表场景

核心参数解析

参数	作用	测试类型
`--test`	指定测试类型	`fileio`（文件 I/O）、`cpu`、`memory`、`threads`
`--oltp-test-mode`	数据库测试模式	`simple`/`complex`/`nontrx`
`--mysql-engine`	MySQL 存储引擎	支持 `innodb`/`myisam`
`--num-threads`	并发线程数	模拟高负载场景

数据库测试核心参数

sysbench \
  --db-driver=mysql \
  --mysql-table-engine=innodb \  # 指定存储引擎
  --table-size=1000000 \         # 测试表数据量 
  --tables=10 \                  # 分表数量 
  --threads=256 \                # 并发线程
  --time=300 \                   # 测试时长(秒)
  /usr/share/sysbench/oltp_read_write.lua run

4 ）数据库基准测试实战

步骤1：初始化测试数据

sysbench oltp_read_write.lua \  
  --db-driver=mysql \  
  --mysql-host=127.0.0.1 \  
  --mysql-port=3306 \  
  --mysql-user=test \  
  --mysql-password=pass \  
  --mysql-db=sbtest \  
  --table-size=1000000 \  
  --tables=10 \  
  prepare  # 初始化10张表，每表100万行

步骤2：执行混合读写测试

sysbench oltp_read_write.lua \  
  --db-driver=mysql \  
  --mysql-db=sbtest \  
  --threads=64 \           # 64并发  
  --time=600 \             # 持续10分钟  
  --report-interval=10 \   # 每10秒输出统计  
  run

关键输出指标：

Queries performed:  
  read: 5.6M            # 总读请求  
  write: 1.2M           # 总写请求  
  total: 6.8M  
Transactions: 34000 (566.5 per sec)  # 事务吞吐量  
Latency (ms): avg 113.2, max 452.1   # 平均/最大延迟

步骤3：清理测试数据

sysbench oltp_read_write.lua \  
  --mysql-db=sbtest \  
  cleanup

5 ) 三大测试场景

文件IO测试

sysbench fileio --file-total-size=20G prepare 
sysbench fileio --file-test-mode=rndrw run

CPU计算能力
```
sysbench cpu --cpu-max-prime=20000 run
```

内存带宽测试

sysbench memory --memory-block-size=1M run

6 ) 自定义Lua测试脚本

这是高级应用

-- custom_oltp.lua
function event()
  -- 随机查询
  rs = db_query("SELECT c FROM sbtest".. math.random(1,10) .." WHERE id=" .. math.random(1,1000000))
  -- 更新操作
  db_query("UPDATE sbtest SET k=k+1 WHERE id=" .. math.random(1,1000000))
end

执行命令：sysbench ./custom_oltp.lua --mysql-host=127.0.0.1 run

SysBench数据库基准测试全流程指南

1 ）基础组件性能测试

1.1. CPU性能测试

sysbench cpu --cpu-max-prime=20000 run  # 测试计算20000以内素数耗时

输出关键指标：

events per second：单核计算能力（值越高性能越优）。
95th percentile：95%请求延迟（如 1.43ms）。

注意：此测试仅针对单核，不涉及多核并发优化

1.2. 磁盘IO测试

步骤1：生成测试文件（需大于内存）

free -m                          # 确认内存大小（示例：512MB）
sysbench fileio --file-total-size=1G prepare  # 生成1G测试文件

步骤2：执行混合读写测试

sysbench fileio --file-test-mode=rndrw \  
               --threads=8 \                # 并发线程数  
               --time=60 \                  # 测试时长（秒）  
               --report-interval=1 run      # 每秒输出统计

参数说明：

--file-test-mode=rndrw：模拟数据库随机读写负载。
输出指标：
- Read (MiB/s)：随机读取吞吐量（如 1.62）。
- Write (MiB/s)：随机写入吞吐量（如 1.0）。
- 95th percentile (ms)：IO响应延迟（如 78.24）。

2 ）数据库基准测试全流程

步骤1：准备测试数据库

CREATE DATABASE sbtest;  
CREATE USER 'sbtest_user'@'localhost' IDENTIFIED BY '123456';    -- 创建用户
GRANT ALL PRIVILEGES ON sbtest.* TO 'sbtest_user'@'localhost';   -- 授权
FLUSH PRIVILEGES;

步骤2：生成测试数据

sysbench oltp_read_write \                  # OLTP读写负载脚本
         --table-size=10000 \               # 单表数据量  
         --tables=10 \                      # 表数量  
         --mysql-db=sbtest \  
         --mysql-user=sbtest_user \  
         --mysql-password=123456 \  
         --mysql-socket=/var/lib/mysql/mysql.sock \  
         prepare                            # 生成数据

步骤3：运行测试并收集指标

# 后台收集系统状态（每5秒采样）  
./collect_stats.sh &  

# 执行OLTP测试
sysbench oltp_read_write \
  --table-size=10000 \
  --tables=10 \
  --mysql-db=sbtest \
  --mysql-user=sbtest_user \
  --mysql-password=123456 \
  --time=60 \
  --threads=8 \
  run

关键输出：

transactions: 105.6 per sec.  # TPS（每秒事务数）  
queries: 1899 per sec.        # QPS（每秒查询数）  
avg latency: 9.47ms           # 平均延迟

步骤4：分析优化效果

对比调优前后TPS与延迟变化：
- TPS提升 → 优化有效。
- 延迟增长 → 需回退配置调整。

监控方案, 系统指标收集脚本：

#!/bin/bash  
while true; do  
  # 采集InnoDB状态  
  mysql -e "SHOW ENGINE INNODB STATUS" >> innodb_status.log  
  # 捕获实时进程  
  mysql -e "SHOW FULL PROCESSLIST" >> processlist.log  
  # 记录全局状态  
  mysql -e "SHOW GLOBAL STATUS" >> global_status.log  
  sleep 5  
done

或

#!/bin/bash
while true; do
# 记录InnoDB状态、进程列表、全局变量
mysql -u sbtest_user -p123456 -e "SHOW ENGINE INNODB STATUS\G" >> innodb_status.log 
mysql -u sbtest_user -p123456 -e "SHOW FULL PROCESSLIST" >> processlist.log
mysql -u sbtest_user -p123456 -e "SHOW GLOBAL STATUS" >> global_status.log
sleep 5  # 每5秒采集一次 
done

3 ）测试结果分析

SysBench输出核心指标：

TPS：105.06 (transactions/sec)     # 每秒事务数  
Reads：1899.22 (reads/sec)         # 每秒读请求  
Writes：210.45 (writes/sec)        # 每秒写请求  
95th percentile：9.47 ms           # 95%请求延迟

性能调优闭环：

建立基准指标（初始测试）
修改数据库参数（如 innodb_buffer_pool_size）
重新执行相同负载测试
对比TPS/延迟变化（例：TPS提升20% → 优化有效）

基准数据用途：
- 硬件性能基线：如CPU计算延迟、磁盘IO吞吐、数据库TPS/QPS。
- 调优效果验证：优化前后对比同一测试的指标变化（如TPS提升20%）。
注意事项：
- 测试文件 > 内存：避免操作系统缓存干扰真实IO性能。
- 真实负载模拟：选择--file-test-mode=rndrw（随机读写）模拟数据库IO模式。

工具对比与选型建议

特性	mysqlslap	sysbench
安装复杂度	MySQL内置	需编译安装
测试维度	纯数据库	系统+数据库
InnoDB支持深度	自动生成表缺索引	完整主键索引支持
扩展性	有限	Lua脚本高度可扩展
适用场景	快速引擎对比	生产环境压测

运维建议：

测试库必须隔离生产环境（--create-schema指定专属库）
InnoDB测试需强制启用自增主键
多次迭代取中位数结果（--iterations>=3）
并发测试递增策略（如10→100→500线程）

通过系统化参数配置和脚本定制，可精准定位数据库瓶颈，为容量规划提供数据支撑。

NestJS 集成基准测试示例

场景：在NestJS服务中嵌入sysbench调用，自动化数据库性能巡检。

import { Injectable } from '@nestjs/common';  
import { execSync } from 'child_process';  
 
@Injectable()  
export class BenchmarkService {  
 
  async runMySQLBenchmark(): Promise<string> {  
    const command = `  
      sysbench oltp_read_write.lua \  
        --db-driver=mysql \  
        --mysql-host=${process.env.DB_HOST} \  
        --mysql-db=test_bench \  
        --threads=100 \  
        --time=60 \  
        run  
    `;  
 
    try {  
      const output = execSync(command, { encoding: 'utf-8' });  
      return this.parseResult(output);  
    } catch (error) {  
      throw new Error(`Benchmark failed: ${error.stderr}`);  
    }  
  }  
 
  private parseResult(raw: string): string {  
    // 提取关键指标（示例）  
    const tpsMatch = raw.match(/transactions:\s+(\d+)\s+\((\d+\.\d+)\s+per sec/);  
    const latencyMatch = raw.match(/latency\s+\(ms\):\s+avg\s+(\d+\.\d+)/);  
 
    return `  
      Transactions/sec: ${tpsMatch[2]}  
      Avg Latency (ms): ${latencyMatch[1]}  
    `;  
  }  
}

Linux目录操作与磁盘空间统计技术详解

1 ) 目录导航操作实践

基础路径切换

在根目录 / 下执行 cd usr 进入 /usr 目录
通过 ls 查看目录内容（含 games 等子目录）
使用 cd games 进入游戏目录，完整路径为 /usr/games
关键符号解析：
- . 表示当前目录（如 cd . 路径不变）
- .. 表示父目录（如 cd .. 回退至 /usr）
- ~ 或 cd（无参数）：直接返回用户家目录（如/home/wang）
- -：（如 cd -）返回上一次所在目录

2 ) 多级路径操作

连续回退两级：cd ../..（从 /usr/games 返回根目录）

绝对路径示例：

cd /usr/games  # 无视当前路径，直接定位

相对路径示例：

cd ../../usr/games  # 从 /home/oscar 出发的相对路径操作

3 ) 路径补全与命令效率优化

Tab键自动补全：
- 输入路径前缀后按Tab自动补全目录名（如输入cd /u + Tab → 补全为/usr）
- 核心价值：避免长路径手动输入错误，提升操作效率

4 ) 用户主目录访问优化

方法	命令示例	优势
绝对路径	`cd /home/oscar`	精准定位
波浪符快捷方式	`cd ~`	系统自动解析主目录
最佳实践	`cd`（无参数）	直接返回当前用户主目录

5 ) Linux路径操作原理

硬链接 vs 软链接

# 创建硬链接（共享inode）  
ln source.txt hardlink.txt  
# 创建软链接（独立inode指向路径）  
ln -s source.txt symlink.txt

du 统计机制：
递归遍历目录树，统计所有文件物理块占用（与 ls 显示的元数据大小本质不同）

6 ) 目录大小统计（du命令）

基本用法：

du /home/wang  # 统计/home/wang目录大小（默认单位：字节）

输出示例：

83948    .  # 总大小83948字节

常用参数：

参数作用示例
-h 人类可读格式（KB/MB/GB） du -h /home → 82M .
-s 仅显示总计大小 du -sh /home → 82M .
-a 显示所有文件/目录详情 du -ah /home → 列出每个子项大小
关键细节：
- 统计原理：du递归遍历子目录计算磁盘占用，与ls仅显示元数据不同。
- 文件缓存影响：若测试文件小于内存，操作系统缓存会导致IO测试失真（需确保测试文件 > 内存）。

参数	作用	示例
`-h`	人类可读格式（KB/MB/GB）	`du -h /home` → `82M .`
`-s`	仅显示总计大小	`du -sh /home` → `82M .`
`-a`	显示所有文件/目录详情	`du -ah /home` → 列出每个子项大小

总结：cd/du/pwd是Linux目录操作核心命令

总结与选型建议

1 ) mysqlslap适用场景：

快速验证基础SQL性能，轻量级测试。
需手动修正自动生成的表结构（添加主键索引）。

2 ) sysbench核心优势：

全栈压力测试（数据库 + 硬件），结果更贴近生产场景。
通过Lua脚本实现高度定制化（如模拟支付事务链）。

3 ) 生产环境注意事项：

测试库必须隔离于业务库（避免DROP TABLE误操作）。
InnoDB测试需预热缓冲池（--warmup-time参数）。
分布式数据库测试增加--tables-count模拟分片逻辑。

工具	核心功能	关键参数/输出
cd	目录切换	`..`（父目录）、`~`（家目录）
du	磁盘使用统计	`-sh`（总大小）、`-a`（含文件）
sysbench	多维度基准测试	`--test=cpu/fileio/oltp`

最佳实践：

新服务器上线前必做 sysbench硬件基准测试（CPU/IO）。
数据库调优后通过 OLTP测试验证TPS与延迟。
测试文件大小需超过内存以避免缓存干扰。

数据库监控增强
InnoDB引擎关键指标：

-- 缓冲池命中率（>99%为优）  
SELECT (1 - (Variable_value / (SELECT Variable_value  
  FROM information_schema.global_status  
  WHERE Variable_name = 'Innodb_buffer_pool_read_requests'))) * 100 AS hit_rate  
FROM information_schema.global_status  
WHERE Variable_name = 'Innodb_buffer_pool_reads';

NestJS集成监控方案

// database-monitor.service.ts  
import { Injectable } from '@nestjs/common';  
import { PrometheusService } from '@nestjs/prometheus';  
 
@Injectable()  
export class DBMetricsService {  
  constructor(private readonly prom: PrometheusService) {}  
 
  recordQuery(duration: number, queryType: string) {  
    this.prom.getHistogram('db_query_duration', 'Database query duration')  
      .observe({ query_type: queryType }, duration);  
  }  
}