01 为什么你需要sysbench和TPC-C？一个测试，两种视角
数据库性能测试不是玄学，是科学。sysbench和TPC-C是业界公认的两大基准测试工具，但它们解决的是不同层面的问题。
sysbench是“微观显微镜”。它测试数据库的极限吞吐能力——每秒能处理多少条SQL语句？CPU、内存、IO哪个是瓶颈？sysbench的OLTP测试模拟简单事务，适合快速定位系统短板。比如，你发现写入速度只有200 TPS，通过sysbench立刻知道是磁盘IOPS不够，还是CPU单核性能不足。
TPC-C是“宏观全景图”。它模拟一个复杂的电商订单系统——5种事务类型（新订单、支付、发货、库存查询、订单状态查询），9张表，严格的ACID约束。TPC-C的测试结果（tpmC，每分钟处理的新订单数）直接对应实际业务场景。一个TPC-C得分10万的数据库，意味着它能支撑日均1440万订单的电商平台。
金句：sysbench测极限，TPC-C测业务；一个看肌肉，一个看脑子。
两者的关系就像体检。sysbench是血常规、尿常规——快速筛查问题；TPC-C是CT、核磁共振——全面诊断病灶。生产环境上线前，两个测试必须都跑一遍。只做sysbench，上线后可能被复杂事务打崩；只做TPC-C，瓶颈定位耗时数天。
02 Docker Compose一键部署：从3天到10分钟
传统部署方式令人崩溃。安装MySQL、配置sysbench、编译TPC-C客户端、处理依赖冲突、调整系统参数……一套流程跑下来，3天起步。环境不一致导致的“在我机器上能跑”问题，更是测试人员的噩梦。
Docker Compose终结这一切。一个docker-compose.yml文件，定义所有服务：MySQL数据库、sysbench客户端、TPC-C客户端、监控工具。docker-compose up -d一键启动，10分钟环境就绪。
示例：Docker Compose配置文件
yaml
version: '3.8'
services:
mysql:
image: mysql:8.0
container_name: db-perf-mysql
environment:
MYSQL_ROOT_PASSWORD: root123
MYSQL_DATABASE: sbtest
ports:
- "3306:3306"
volumes:
- ./mysql-data:/var/lib/mysql
command: --default-authentication-plugin=mysql_native_password
deploy:
resources:
limits:
cpus: '4'
memory: 8G
sysbench:
image: severalnines/sysbench
container_name: db-perf-sysbench
depends_on:
- mysql
entrypoint: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
tpcc:
image: perconalab/sysbench:latest
container_name: db-perf-tpcc
depends_on:
- mysql
entrypoint: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
volumes:
- ./tpcc-scripts:/scripts
grafana:
image: grafana/grafana:latest
container_name: db-perf-grafana
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
volumes:
- ./grafana-data:/var/lib/grafana
部署命令：
bash
# 启动所有服务
docker-compose up -d
# 查看容器状态
docker-compose ps
# 进入sysbench容器
docker exec -it db-perf-sysbench /bin/bash
# 进入TPC-C容器
docker exec -it db-perf-tpcc /bin/bash
关键设计点：
- ►资源限制：
deploy.resources.limits防止测试时容器抢占宿主机资源
- ►持久化存储：
volumes挂载数据目录，测试结果可复现
- ►等待依赖：
depends_on确保MySQL先启动，但需额外等待就绪
- ►监控集成：Grafana容器预置，可连接Prometheus实时查看性能指标
金句：环境搭建的痛苦，Docker Compose一键化解。
03 sysbench实战：5分钟跑出数据库极限
进入sysbench容器后，执行以下步骤：
步骤1：准备测试数据
bash
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=mysql \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=root123 \
--mysql-db=sbtest \
--table-size=1000000 \
--tables=10 \
prepare
参数说明：创建10张表，每张表100万行数据，总计1000万行。数据量太小无法压测出真实瓶颈。
步骤2：执行压力测试
bash
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=mysql \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=root123 \
--mysql-db=sbtest \
--table-size=1000000 \
--tables=10 \
--threads=64 \
--time=300 \
--report-interval=10 \
run
关键参数：--threads=64并发线程数，--time=300测试持续5分钟，--report-interval=10每10秒输出一次结果。
步骤3：分析结果
输出示例：
text
SQL statistics:
queries performed:
read: 1428570
write: 408160
other: 204080
total: 2040810
transactions: 102040 (340.13 per sec.)
queries: 2040810 (6802.70 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Latency (ms):
min: 1.23
avg: 18.81
max: 345.67
95th percentile: 42.10
sum: 1920000.00
Threads fairness:
events (avg/stddev): 1594.3750/12.45
execution time (avg/stddev): 30.0000/0.02
解读：
- ►
340.13 per sec.：每秒处理340个事务（TPS），这是核心指标
- ►
95th percentile: 42.10ms：95%的请求延迟低于42ms，用户体验关键指标
- ►
Threads fairness：线程负载均衡度，stddev越小越好
步骤4：清理数据
bash
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=mysql \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=root123 \
--mysql-db=sbtest \
cleanup
金句：TPS是肌肉，延迟是神经；肌肉再大，神经慢了也白搭。
04 TPC-C实战：模拟电商系统真实负载
TPC-C测试更贴近业务，使用Percona提供的sysbench变体。
步骤1：准备TPC-C数据
bash
# 进入TPC-C容器
docker exec -it db-perf-tpcc /bin/bash
# 创建TPC-C测试数据库
mysql -h mysql -u root -proot123 -e "CREATE DATABASE tpcc100;"
# 准备数据：100个仓库（约10GB数据）
sysbench /usr/share/sysbench/tpcc.lua \
--mysql-host=mysql \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=root123 \
--mysql-db=tpcc100 \
--tables=9 \
--scale=100 \
--db-driver=mysql \
prepare
--scale=100表示100个仓库，对应约10000个商品、10万个客户、1000万级订单数据量。
步骤2：执行TPC-C测试
bash
sysbench /usr/share/sysbench/tpcc.lua \
--mysql-host=mysql \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=root123 \
--mysql-db=tpcc100 \
--tables=9 \
--scale=100 \
--threads=32 \
--time=600 \
--report-interval=30 \
--db-driver=mysql \
--trx_level=RC \
--mysql-ignore-errors=1213,1181,1205 \
run
关键参数：--time=600测试10分钟，--trx_level=RC使用读已提交隔离级别，--mysql-ignore-errors忽略死锁等可重试错误。
步骤3：解读TPC-C结果
输出示例：
text
SQL statistics:
queries performed:
read: 2857140
write: 816320
other: 408160
total: 4081620
transactions: 204080 (340.13 per sec.)
queries: 4081620 (6802.70 per sec.)
Latency (ms):
min: 2.34
avg: 47.12
max: 892.01
95th percentile: 156.30
TPC-C throughput:
new_order: 102040 (170.07 tpmC)
payment: 102040 (170.07 tpmC)
order_status: 20408 (34.01 tpmC)
delivery: 10204 (17.01 tpmC)
stock_level: 10204 (17.01 tpmC)
核心指标：
- ►
170.07 tpmC：每分钟处理170个新订单，这是TPC-C的权威指标
- ►5种事务比例：新订单45%、支付43%、订单状态4%、发货4%、库存4%
- ►延迟分布：95分位156ms，符合OLTP系统要求（<200ms）
步骤4：调整参数优化
发现瓶颈后，调整MySQL配置：
sql
-- 优化innodb缓冲池
SET GLOBAL innodb_buffer_pool_size = 6 * 1024 * 1024 * 1024; -- 6GB
-- 增加并发连接数
SET GLOBAL max_connections = 500;
-- 调整日志文件大小
SET GLOBAL innodb_log_file_size = 2 * 1024 * 1024 * 1024; -- 2GB
-- 启用查询缓存（谨慎使用）
SET GLOBAL query_cache_type = 0; -- 关闭，避免锁竞争
重新测试，观察tpmC提升幅度。
金句：TPC-C的tpmC，是数据库的“高考分数”，一分差距，天壤之别。
05 从测试到优化：一个完整的性能调优闭环
跑完测试只是开始，真正的价值在于数据驱动优化。
数据采集与监控
在Docker Compose中加入Prometheus + Node Exporter + MySQL Exporter：
yaml
prometheus:
image: prom/prometheus:latest
container_name: db-perf-prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
node-exporter:
image: prom/node-exporter:latest
container_name: db-perf-node-exporter
ports:
- "9100:9100"
mysql-exporter:
image: prom/mysqld-exporter:latest
container_name: db-perf-mysql-exporter
environment:
DATA_SOURCE_NAME: "root:root123@tcp(mysql:3306)/"
ports:
- "9104:9104"
通过Grafana仪表盘，实时查看CPU、内存、磁盘IO、MySQL QPS、连接数、锁等待等指标。
性能调优闭环
1. 发现瓶颈：sysbench显示IO延迟高，磁盘队列深度大
2. 定位根因：MySQL Exporter显示innodb_log_writes等待频繁
3. 提出方案：增加innodb_log_file_size至2GB，innodb_flush_log_at_trx_commit=2
4. 验证效果：重新跑sysbench，TPS从340提升至520，提升53%
5. 回归测试：跑TPC-C，tpmC从170提升至240，提升41%
常见陷阱与解决方案
| 问题 | 现象 | 解决方案 |
|---|
| 连接数不足 | sysbench报错`Too many connections` | 增大`max_connections`，使用连接池 |
| 死锁频发 | TPC-C报错`Deadlock found` | 调整事务隔离级别为RC，优化SQL索引 |
| 磁盘IO瓶颈 | iowait>50% | 使用SSD，调整`innodb_io_capacity` |
| 内存不足 | Swap使用率>10% | 增大`innodb_buffer_pool_size`至内存70% |
金句：没有数据的优化是赌博，有数据的优化是科学。
---
总结：Docker Compose一键部署，sysbench测极限，TPC-C测业务，数据驱动闭环。你的数据库性能，不该靠猜。
行动指令：今天就用这套方案，测出你数据库的tpmC，然后优化它。
声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。
京公网安备
11010802035719号