sysbench命令报“command not found”主因是二进制路径未加入PATH，源码安装后需手动软链或配置环境变量；prepare报“Unknown database ‘sbtest’”因库未创建且用户缺建库权限；连接失败多因参数名不匹配或MySQL绑定IP导致socket/TCP混淆；并发低常因max_connections限制或InnoDB锁争用。
sysbench 安装后 sysbench 命令报 “command not found”
常见于 Linux 发行版未将 sysbench 二进制路径加入 $PATH，尤其是源码编译安装后。Debian/Ubuntu 用 apt 安装一般没问题，但 CentOS Stream 或自建 RPM 包容易漏掉软链。
- 先确认是否真装上了：
find /usr -name "sysbench" 2>/dev/null，常见位置是/usr/local/bin/sysbench - 如果找到了，执行
sudo ln -sf /usr/local/bin/sysbench /usr/bin/sysbench（或直接把/usr/local/bin加进/etc/environment） - 别用
./sysbench临时跑——压测脚本里写死路径易出错，且无法被系统服务调用
准备数据库时 sysbench prepare 报错 “Unknown database ‘sbtest’”
sysbench 默认用 sbtest 库，但它不会自动创建。很多人卡在这步，以为是权限问题，其实是库不存在 + 用户没建库权限的组合问题。
- 先手动建库：
mysql -u root -p -e "CREATE DATABASE sbtest CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" - 再授权（别只给
sbtest.*）：GRANT ALL ON sbtest.* TO 'sbuser'@'localhost'; FLUSH PRIVILEGES; - 注意：MySQL 8.0+ 默认认证插件是
caching_sha2_password，sysbench 1.0.x 不兼容，建用户时得显式指定：CREATE USER 'sbuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pass123';
sysbench oltp_read_write 启动就报 “FATAL: unable to connect to MySQL server”
不是密码错了，而是连接参数没对齐。sysbench 的 MySQL 连接参数名和 MySQL 客户端不一致，比如它用 --mysql-host 而不是 -h，漏一个就静默失败。
- 必传参数一个都不能少：
--mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=sbuser --mysql-password=pass123 --mysql-db=sbtest - 如果 MySQL 绑定了
127.0.0.1（而非localhost），就别用localhost——MySQL 会走 socket，而 sysbench 强制走 TCP，必须填 IP - 加
--debug可看到真实连接日志，比光看 FATAL 有用得多
并发数设成 512，但 SHOW PROCESSLIST 看到只有几十个活跃连接
sysbench 的 --threads 控制的是客户端线程数，不是 MySQL 的并发连接上限。真正卡住的往往是 MySQL 自身配置，尤其是 max_connections 和 innodb_buffer_pool_size。
- 检查 MySQL 实际限制：
SELECT @@max_connections, @@innodb_buffer_pool_size;，max_connections默认常是 151，不够就得改my.cnf - buffer pool 太小会导致频繁刷盘，CPU 没打满、IOPS 却飙高，表现就是 QPS 上不去、延迟毛刺多
- 别盲目加线程：从 16 开始逐步翻倍测试，观察
Threads_running和Innodb_row_lock_waits，后者持续上升说明锁争用已成瓶颈
压测时最容易被忽略的是 MySQL 的 wait_timeout 和 sysbench 的连接复用策略——短连接模式下，反复建连/销毁本身就会吃掉可观 CPU，这时看到的“并发低”其实是连接管理开销掩盖了真实负载能力。
