sysbench报错因mysql客户端库缺失或路径未配置，需安装mysql-devel、配置ldconfig；测试前须建专用库、禁用查询缓存、调优innodb缓冲池；关键参数包括--threads、--time等；结果应关注stddev、errors及95th响应时间。
sysbench 安装后运行报错 command not found 或 libmysqlclient.so.21: cannot open shared object file
常见于 CentOS/RHEL 系统上直接用源码编译安装，但没配置动态库路径或 MySQL 客户端开发包缺失。不是 sysbench 本身坏了，而是它找不到 MySQL 的底层连接库。
- 先确认 MySQL 开发包已装：
yum install mysql-devel（CentOS 7）或dnf install mysql-devel（CentOS 8+/RHEL 9） - 若用源码编译，务必加
--with-mysql参数，并确保mysql_config在$PATH中；可运行which mysql_config验证 - 动态库报错时，执行
ldconfig -p | grep mysql看是否注册成功；若无，手动追加路径到/etc/ld.so.conf.d/mysql.conf，再跑ldconfig
准备测试前必须做好的三件事：清空 sysbench 测试库、禁用查询缓存、确认 InnoDB 缓冲池大小
很多人跳过初始化步骤，直接跑 sysbench oltp_read_write，结果第一次结果偏低、后续又偏高——本质是数据未预热、缓冲池被污染、MySQL 自身缓存干扰了真实 I/O 压力。
- 建专用测试库：
CREATE DATABASE sbtest CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，别复用业务库 - 关掉查询缓存（MySQL 8.0+ 已移除，但 5.7 需设
query_cache_type=0并重启） - InnoDB 缓冲池至少设为物理内存的 50%～70%，且大于测试数据集（例如 100 万行约需 1.2GB），否则大量页淘汰会掩盖磁盘性能
sysbench --db-driver=mysql 下最关键的五个参数及其影响
这些参数不调好，测出来根本不是数据库能力，而是网络延迟、单线程瓶颈或 SQL 解析开销。
-
--threads=N：不是越多越好。超过 CPU 核心数 × 2 后，上下文切换开销剧增；建议从 4、8、16、32 逐级测，观察 QPS 是否线性增长 -
--time=60：必须设足够长（至少 60 秒），短于 20 秒的结果抖动极大，尤其在 SSD 上 -
--report-interval=10：每 10 秒输出一次实时指标，方便观察是否稳定；若前 10 秒 QPS 很低，后 10 秒飙升，说明预热不足或锁竞争严重 -
--tables=16和--table-size=100000：表太少会集中锁争用；单表太大则ALTER TABLE初始化慢、且易触发长事务阻塞；16 表 × 10 万行是较平衡起点 -
--mysql-db=sbtest和--mysql-user=root：必须显式指定，否则默认连test库，而该库可能被禁用或权限受限
跑完 sysbench 后怎么看结果才不算白测
只盯着最后一行的 queries: 或 transactions: 是最大误区。真正反映数据库吞吐和稳定性的是中间时段的持续表现，以及错误率。
- 重点看
tps（每秒事务数）和qps（每秒查询数）的「stddev」值：若标准差 > 均值的 15%，说明响应时间抖动大，可能存在锁等待、刷脏页卡顿或 NUMA 不均衡 - 检查
errors:行：哪怕只有0.01%的mysql_stmt_execute错误，也意味着连接池耗尽或超时设置过短 - 对比
read/write/other的响应时间中位数（95th percentile）：若 write 响应时间突增 3 倍，而 read 稳定，大概率是 redo log 刷盘慢或 binlog 组提交未生效
pt-stalk 或 mysqld_exporter + Grafana 同步采集 MySQL 内部指标”。没有 InnoDB_row_lock_waits、Threads_running、innodb_log_waits 这些维度，光靠 sysbench 输出，等于蒙眼调优。
