装完mysql需先用mysqlslap验证连通性与并发响应，再用sysbench做oltp压力测试；二者分阶段使用，前者查单点问题，后者验整体瓶颈，且均须基于真实数据量和业务sql。
装完 MySQL 不能直接上线，得先确认它在你这台机器上“能跑、能扛、不抽风”。最直接的办法就是用 mysqlslap 快速过一遍基础响应和并发能力，再用 sysbench 模拟真实读写负载——这两个工具不是选一个，而是分阶段用：前者查单点问题，后者验整体瓶颈。
用 mysqlslap 验证服务连通性与简单查询响应
这是装完 MySQL 后第一道门槛。别急着跑默认命令，mysqlslap --auto-generate-sql 在空库里生成 100 行假数据，测出来全是内存命中，完全没意义。
- 必须显式指定已有数据库：
--database=testdb，且该库需已存在（mysqlslap不会自动建库） - 用
--query指向一条真实业务 SQL，比如SELECT id, name FROM users WHERE status = ?，避免随机语句掩盖索引失效 - 并发控制靠
--concurrency（连接数），不是线程数；设为10就是同时打开 10 个连接发请求 - 加
--iterations=3多跑几轮，排除网络抖动或临时锁等待干扰
常见失败：Unknown database 'testdb' 是库不存在；Access denied 是账号没 SELECT 权限；响应时间高但业务不卡？检查是否误加了 --no-defaults，跳过了 my.cnf 里的超时配置。
用 sysbench 做 OLTP 级别压力测试
sysbench 是唯一能让你看清“QPS 上不去到底是 CPU、IO 还是锁拖后腿”的工具。但直接 apt install sysbench 在 MySQL 8.0+ 上大概率报错：Authentication plugin 'caching_sha2_password' cannot be loaded——因为包管理器装的版本链接的是旧 client lib。
- 必须源码编译：
./configure --with-mysql-includes=/usr/local/mysql/include --with-mysql-libs=/usr/local/mysql/lib，路径按你实际 MySQL 安装位置填 - prepare 阶段前，手动执行：
CREATE DATABASE sbtest CHARACTER SET utf8mb4和GRANT ALL ON sbtest.* TO 'sbuser'@'localhost'，sysbench不建库也不授权 - 避免 prepare 卡死：加
--threads=8并关掉 autocommit（--mysql-autocommit=off），否则单线程插百万行慢到怀疑人生 - 压测时别只看平均延迟，盯住
p95 latency和mysqladmin processlist里有没有Waiting for table metadata lock——那是老版本sysbench在 run 阶段偷偷 ANALYZE TABLE 导致的元数据锁冲突
监控必须同步开启，不能等压测结束再看
光跑工具不看监控，等于蒙眼开车。QPS 突然掉下去，可能不是 SQL 问题，而是 max_connections 被打满，或者网卡吞吐见顶。
- 实时查连接数：
mysqladmin extended-status -r -i 1 | grep Threads_connected - 看 IO 是否瓶颈：
iostat -x 1关注%util和await，持续 >90% 或 await >20ms 就要怀疑磁盘 - InnoDB 缓冲池是否够用：
mysqladmin extended-status | grep Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，后者除以前者结果 >1% 说明大量走磁盘 - 别漏掉系统级指标：
top看 CPU 是否被 mysqld 占满，还是被sysbench进程吃掉——后者说明压测机本身成了瓶颈
真正容易被忽略的点是：所有测试都必须基于**有代表性的数据量**。用 1 万行表测出来的索引优化效果，在生产千万级表上可能完全不成立；而 sysbench 默认的 oltp_read_write.lua 脚本每事务只操作一行，和你业务里一次更新 50 行的锁竞争强度天差地别——脚本行为差异比参数本身更影响结论。
