sysbench安装失败主因是系统源版本过旧或缺失依赖，ubuntu/debian建议用官方源安装并验证版本≥1.0.20，centos/rhel需手动编译，mac需通过homebrew正确安装含mysql支持版本；连不上mysql需检查驱动、用户权限及socket路径；prepare卡住多因引擎、字符集不兼容，应指定innodb与utf8mb4；压测不准常因未预热buffer pool、连接数不足或mysql配置未优化。
sysbench 命令装不上：缺依赖或源不对
直接 apt install sysbench 或 yum install sysbench 失败，大概率是系统默认源没打包，或者版本太老（比如 CentOS 7 默认只有 0.4.12，不支持 MySQL 8.0+ 的认证插件）。Ubuntu 22.04+、Debian 12 这类新系统反而自带较新版本，但也要确认。
- Ubuntu/Debian 推荐用官方源安装：
sudo apt update && sudo apt install sysbench，装完检查版本：sysbench --version，低于 1.0.20 就别硬用，尤其连 MySQL 8.0 会报Plugin caching_sha2_password could not be loaded - CentOS/RHEL 7/8 必须手动编译：先装依赖
sudo yum install gcc make automake autoconf libtool openssl-devel mysql-devel（RHEL 8 改用dnf），再从 github 下载 1.0.20+ 源码编译，./autogen.sh && ./configure --with-mysql && make && sudo make install - Mac 用户用 Homebrew：
brew install sysbench，但注意它默认不带 MySQL 支持，得重装：brew uninstall sysbench && brew install sysbench --with-mysql（Homebrew 4.0+ 已弃用--with-参数，此时需改用brew install sysbench并确保mysql-client已存在）
连不上 MySQL：驱动、用户权限、socket 路径三处常翻车
运行 sysbench oltp_read_write --db-driver=mysql ... prepare 报错连不上，不是密码错就是驱动没认全。sysbench 本身不自带 MySQL 客户端库，靠系统已装的 libmysqlclient 或 mysqlclient 动态链接，路径、版本、权限都得对上。
- 确认 MySQL 客户端库已安装：
mysql --version能跑，且ldconfig -p | grep mysql能看到libmysqlclient.so；若用 mariadb，要装mariadb-devel而非mysql-devel - MySQL 用户必须有远程访问权限（哪怕本地测试也建议用
localhost而非127.0.0.1，避免走 TCP 引发 socket 权限问题）；执行：CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'pass'; GRANT ALL ON sbtest.* TO 'sbtest'@'localhost'; FLUSH PRIVILEGES; - unix socket 路径不一致会静默失败：MySQL 配置里
socket=/var/run/mysqld/mysqld.sock，但 sysbench 默认找/tmp/mysql.sock；加参数强制指定：--mysql-socket=/var/run/mysqld/mysqld.sock
prepare 阶段卡住或报错：引擎、字符集、大表初始化慢
sysbench oltp_common --tables=16 --table-size=1000000 prepare 执行半天没反应，或报 Error 1071 (42000): Specified key was too long，本质是建表语句和当前 MySQL 配置不兼容。
- InnoDB 行格式影响索引长度：MySQL 5.7+ 默认
ROW_FORMAT=DYNAMIC，但若表定义里显式写了ROW_FORMAT=COMPACT，而字段含长VARCHAR+utf8mb4，就容易超 767 字节限制；加参数绕过：--mysql-storage-engine=innodb --db-ps-mode=disable（禁用预处理，减少元数据干扰） - 大表初始化极慢：
--table-size=1000000生成百万行，单线程默认要几分钟；加--threads=4可提速，但注意这仅加速 prepare，不影响后续压测线程数 - 字符集别硬写：sysbench 内置建表 SQL 默认用
utf8，但 MySQL 8.0+ 默认utf8mb4；加--mysql-db=sbtest --mysql-table-options="default CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci"显式对齐
压测结果不准：时间精度、连接池、冷启动干扰
跑完 run 看 QPS 波动极大，或和预期差几倍，往往不是 SQL 本身问题，而是环境没“稳住”。
- MySQL 查询缓存已废弃（8.0 移除），但 InnoDB buffer pool 若没预热，头几十秒全是磁盘 IO；先跑一次短时 warmup：
sysbench ... --time=30 run，再正式测 - sysbench 默认每线程独占连接，16 线程 = 16 个长连接；MySQL 的
max_connections至少设到 200 以上，否则中途报Too many connections - 时间统计受系统调度影响：别在笔记本后台开 chrome 测，关掉定时任务、swap（
sudo swapoff -a），用--time=300跑够 5 分钟，避开前 10 秒的抖动 - 输出里的
queries:是总请求数，transactions:是事务数，OLTP 场景下二者通常 1:1；若看到queries远大于transactions，说明用了--db-ps-mode=auto导致预处理被反复编译，加--db-ps-mode=disable锁死
最麻烦的是 MySQL 自身配置没调：比如 innodb_buffer_pool_size 小于数据集，压测全程在刷脏页；或者 sync_binlog=1 强制刷盘，QPS 直接砍半。这些不在 sysbench 控制范围内，但不调就等于拿拖拉机跑赛道。