mysqlslap适合快速验证单条sql在不同并发下的平均耗时，如加索引前后效果、mysql版本baseline对比、新服务器连接池配置检查，但不支持自定义表结构，仅输出单一均值，无法反映真实业务负载。
直接用 mysqlslap 就能快速验证基础并发能力，但别指望它发现复杂业务下的锁竞争或长事务问题；真要测生产级负载，得上 sysbench 或 JMeter，否则容易误判瓶颈位置。
mysqlslap 适合什么场景？
它只做一件事：快速跑通一条 SQL 在不同并发下的平均耗时。适合验证单条查询加索引前后效果、对比两个 MySQL 版本的 baseline 性能、或者检查新服务器的连接池配置是否生效。
- 不支持自定义表结构，
--auto-generate-sql生成的表和数据分布极简，跟真实业务脱节 -
--concurrency=10,50,100是梯度测试，不是持续压测；每次运行都会重建表、清空数据，无法观察内存/缓冲池长期表现 - 输出里没有错误率、95% 延迟、QPS 曲线——只有“总耗时 / 查询数”这个单一均值，掩盖毛刺和失败请求
- 如果连不上库，报错是
Access denied for user或Can't connect to MySQL server，但不会告诉你具体卡在 DNS 解析、SSL 握手还是认证超时
sysbench 必须配哪些参数才不白跑？
sysbench 的坑不在安装，而在参数组合。漏掉任意一个关键项，结果就不可比。
-
--threads要阶梯递增（比如 16→32→64→128），不能只跑一次；单次结果受 CPU 调度抖动影响太大 -
--time=300（5 分钟）是底线，短于 60 秒的结果基本无效——InnoDB 缓冲池没热起来，磁盘 IO 没稳定，数据全在 page cache 里骗人 - 必须显式指定脚本路径：
/usr/share/sysbench/oltp_read_write.lua，别用默认的oltp_point_select——它只查主键，完全绕过索引扫描和锁机制 -
--report-interval=10开启实时输出，每 10 秒打印一次 QPS 和延迟，才能看出拐点在哪（比如线程从 64 增到 128 时，P95 延迟突然从 20ms 涨到 200ms）
JMeter 连 MySQL 容易卡在哪？
JDBC 连接池配置不对，90% 的问题都出在这儿，而不是 SQL 本身。
-
max_connections在 MySQL 侧设了 2048，但 JMeter 的Number of Threads设成 500，每个线程开一个连接——瞬间打满连接数，后续请求全卡在Waiting for connection - JDBC URL 必须加
useServerPrepStmts=true&cachePrepStmts=true，否则 prepareStatement 重复编译，CPU 直接飙高 - 别信“自动提交”开关：JMeter 默认
Auto Commit打开，但如果你的测试 SQL 包含UPDATE，没手动 commit 就 close，事务会回滚，QPS 看着高，实际啥都没写进去 - 响应时间监控只看
Response Time不够，得在View Results Tree里点开失败请求，错误信息通常是Communications link failure（网络中断）或Lock wait timeout exceeded（死锁），这两者处理方式完全不同
压测时最常被忽略的三件事
不是工具跑起来就算完事。真正的问题往往藏在工具之外。
- 没开慢查询日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.1;，否则你根本不知道哪条 SQL 在拖后腿 - 没盯
SHOW ENGINE INNODB STATUS\G输出里的SEMAPHORES和TRANSACTIONS部分——线程等锁、锁等待队列长度、事务回滚率，这些才是并发瓶颈的直接证据 - 测试数据量太小：用
sysbench准备 10 万行数据，但生产表有 5000 万行；B+ 树深度差 3 层，随机 IO 成本差 10 倍，测出来的延迟毫无参考价值
