SQL性能压测是验证数据库在不同负载下表现的重要手段，通过模拟真实业务流量可以提前暴露慢查询、锁竞争和资源不足等问题。完整的压测与瓶颈定位流程包含准备、执行、监控和分析四个阶段，下面按步骤说明。
一、压测前准备
明确压测目标，例如验证某报表SQL在500并发下响应时间小于1秒。准备接近生产的数据量，避免用小表测出的结果误导判断。常见工具有 sysbench、JMeter 以及数据库自带的基准套件。
1.1 数据与环境
- 使用生产脱敏数据或按比例放大生成数据
- 关闭自动备份等干扰任务
- 记录基线配置如缓冲池大小
二、执行SQL性能压测
以 sysbench 为例，可编写自定义SQL脚本进行压测。以下为简单示例，演示如何调用 oltp_read_only 模式压测：
# 准备测试数据 sysbench oltp_read_only --db-driver=mysql --mysql-host=127.0.0.1 --mysql-user=test --mysql-password=test --tables=10 --table-size=100000 prepare # 运行压测 500线程 持续60秒 sysbench oltp_read_only --threads=500 --time=60 run
2.1 监控指标
压测时重点看吞吐（QPS/TPS）、响应时间分布和错误率，同时用系统工具观察 CPU、IO 与内存。
| 指标 | 说明 |
|---|---|
| QPS | 每秒查询数 |
| Latency | 平均及百分位延迟 |
| CPU util | 是否出现单核跑满 |
三、瓶颈定位流程
压测结束后若指标不达标，按以下顺序排查：
3.1 慢查询与执行计划
开启慢查询日志，用 EXPLAIN 查看是否全表扫描。注意函数调用如 count() 本身不会引发扫描，但写法不当会让索引失效。
-- 查看执行计划 EXPLAIN SELECT user_id FROM orders WHERE create_time > '2023-01-01'; -- 开启慢日志 SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5;
3.2 锁与并发
高并发下常因行锁或表锁导致等待。可通过 information_schema 下的锁视图分析阻塞源。
3.3 资源瓶颈
若 CPU 低但 IO 高，多为磁盘吞吐不足；若内存换页频繁，应调大缓冲池。硬件限制需用 top 与 iostat 交叉确认。
四、小结
SQL性能压测不是单纯跑分，而是用数据定位瓶颈。遵循准备、压测、监控、分析四步，结合慢日志与执行计划，能高效找到数据库优化的切入点。