MySQL压测并发数应贴近线上真实请求模型，根据生产QPS与平均响应时间估算（如200 QPS×0.05s=10），并受max_connections限制；sysbench中--threads控制并发度，--time决定时长，--events为请求数上限；需关注锁竞争、执行计划退化、连接复用及buffer pool预热等问题。
MySQL压测时并发数到底设多少才真实？
并发数不是越大越好，它得贴近你线上业务的真实请求模型。盲目调高 threads 或 --threads，只会把压测变成“打自己”，掩盖真实瓶颈，甚至触发连接池耗尽、线程争抢锁、主从延迟飙升等问题。
- 先查生产环境平均 QPS 和峰值 QPS，再结合单次查询平均响应时间估算合理并发：比如平均响应 50ms，目标压到 200 QPS，理论并发 ≈ 200 × 0.05 = 10；实际可从 8 起步，逐步加到 20–40 观察稳定性
- 注意 MySQL 的
max_connections配置——压测并发不能超过它减去系统保留连接（如监控、备份）的余量，否则直接报错Too many connections - 用
sysbench时，--threads=32表示客户端模拟 32 个并发线程，但每个线程默认复用连接；若脚本里手动建连不释放，实际数据库连接数可能远超该值
sysbench 里 --threads 和 --time/--events 哪个控制真实压力？
--threads 决定并发度，--time 决定压测持续时长，--events 是总请求数上限——三者关系是：实际执行请求数 ≈ --threads ×（每秒完成数）× --time，但受 --events 截断。
- 线上突发流量是短时高峰，用
--time=60 --threads=24比固定--events=100000更贴近真实场景 - 如果
--events设得太小（比如 100），压测几秒就结束，根本看不出连接池或慢查询积压问题 -
--time过短（如 5 秒）会导致 warmup 不足，前几秒数据抖动大，建议至少 30 秒，稳定后取后 20 秒指标
为什么压测 QPS 上不去，但 CPU 和 IO 都不高？
常见原因是锁竞争或事务串行化阻塞，尤其在迁移后表结构/索引未适配新负载，或隔离级别过高（如 REPEATABLE-READ 下间隙锁激增）。
- 检查
SHOW ENGINE INNODB STATUS\G中的TRANSACTIONS部分，看是否有大量lock wait或trx has been waiting - 对比迁移前后执行计划：用
EXPLAIN FORMAT=TRADITIONAL看是否走了全表扫描，或用了临时表/文件排序——这些在并发下会指数级放大开销 - 确认压测 SQL 是否含
FOR UPDATE或写操作；读写混合压测中，一个慢更新可能拖垮所有读线程
压测结果里 latency 波动大，怎么定位是数据库还是网络或客户端？
先排除客户端瓶颈：sysbench 默认单进程多线程，当 --threads > 核心数×2 时，CPU 上下文切换开销会明显抬高延迟毛刺。
- 在压测机上运行
top -H -p $(pgrep sysbench)，观察各线程 CPU 占用是否严重不均——不均说明某些线程卡在锁或 I/O 上 - 用
tcpdump抓包比对客户端发包时间戳和 MySQL 返回时间戳，若间隔集中在服务端，再查slow_query_log和performance_schema.events_statements_summary_by_digest - 别忽略连接建立开销：如果压测脚本每次请求都
mysql_real_connect()，而不是复用连接，handshake时间会吃掉大量99th percentile延迟
innodb_buffer_pool 缓存，导致第一次跑全是内存命中，后续才暴露出磁盘 I/O 瓶颈。 
