mysqlslap不能直接测出生产瓶颈，因其轻量级设计缺乏连接池、事务交织、锁竞争和MVCC冲突模拟等真实负载特征。
mysqlslap 能不能直接测出生产瓶颈
不能，mysqlslap 是个轻量级模拟工具，适合快速验证 SQL 基础性能或对比不同索引效果，但默认行为离真实业务负载差得远。它不维持连接池、不复用预处理语句、不模拟事务交织，更不会触发 InnoDB 的锁竞争或 MVCC 冲突——这些才是线上慢的主因。
实操建议：
- 必须用
--concurrency和--iterations组合压出持续并发，单次短跑没意义 - 加
--create-schema避免测试时建库干扰结果，但要确保目标库已存在且权限正确 - 默认用
SELECT，想测写入得显式写--query="INSERT ..."，否则全在读缓存里跑 - 不加
--auto-generate-sql时，SQL 必须写完整，字段名、表名都要带反引号（如`user_id`），否则报错Unknown column
mysqlslap 报错 “Access denied for user” 怎么解
不是密码错了，大概率是账号没被授权从测试发起机登录。mysqlslap 默认走 TCP 连接（哪怕本机也走 127.0.0.1），而 MySQL 的 localhost 用户只认 socket 连接，两者权限记录是分开的。
实操建议：
- 用
mysql -h 127.0.0.1 -u test -p先手动连一次，确认账号是否支持 TCP 登录 - 如果不行，执行
CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; GRANT ALL ON testdb.* TO 'test'@'127.0.0.1'; - 避免用
-h localhost，改用-h 127.0.0.1或实际 IP，防止客户端自动降级走 socket - 密码含特殊字符（如
$、@）必须用单引号包裹：-p'p@ss$word'，否则 shell 会提前解析
怎么让 mysqlslap 更贴近真实业务请求
靠参数拼凑不如直接喂真实 SQL。自动生成的语句太均匀，没有热点行、没有长事务、没有混合读写比例，压不出锁等待和 buffer pool 淘汰问题。
实操建议：
- 从 slow log 或
performance_schema.events_statements_summary_by_digest里抽 Top 10 查询，拼成文件queries.sql - 用
--query=/path/to/queries.sql --delimiter=";"加载，注意每条 SQL 结尾要有分号 - 加
--commit=10让每 10 条 INSERT 自动提交，模拟小批量写入；不加则全塞进一个事务，测的是日志刷盘能力而非并发控制 - 用
--number-of-queries=1000控制总请求数，比单纯跑固定时间更可控，避免因服务器卡顿导致结果失真
mysqlslap 测出来 QPS 很高，但线上还是慢
因为 mysqlslap 测的是“单语句平均响应”，而线上慢往往卡在锁等待、磁盘 IO 等待、连接建立开销上——这些它默认不统计也不触发。
实操建议：
- 加
--verbose看每轮实际耗时分布，关注 max/min/stddev，如果标准差极大，说明有阻塞但你没意识到 - 配合
SHOW ENGINE INNODB STATUS\G在压测中查SEMAPHORES和TRANSACTIONS区块，看有没有lock wait累积 -
mysqlslap不测网络延迟，如果压测机和 DB 不在同一内网，TCP RTT 会吃掉大量时间，此时 QPS 低是正常现象 - 真正要定位线上瓶颈，得用
pt-query-digest分析慢日志，或打开performance_schema抓锁事件，别指望一个命令行工具包打天下
工具只是镜子，照得清不清，取决于你让它照哪、怎么调焦距。mysqlslap 的默认参数，连镜面都没擦干净。
