mysql如何查看数据库的最大吞吐量性能_使用sysbench进行压力测试-mysql教程-PHP中文网

创建专用用户并指定认证插件可解决sysbench 5.7+连接MySQL 8.0的ERROR 1045；--tables和--table-size决定数据规模与资源消耗；--time与--events互斥；queries是SQL总数，transactions是事务数，比例为3:1；95th延迟比平均值更具参考价值。

mysql如何查看数据库的最大吞吐量性能_使用sysbench进行压力测试

sysbench 5.7+ 版本连接 MySQL 8.0 报错 `ERROR 1045 (28000): Access denied` 怎么办

默认 sysbench 会尝试用 root@localhost 连接，但 MySQL 8.0 默认禁用 mysql_native_password 插件，且 root 用户可能被限制为 caching_sha2_password 认证方式。直接连会因插件不兼容或权限不足失败。

创建专用测试用户（避免改 root）：

CREATE USER 'sbtest'@'localhost' IDENTIFIED WITH mysql_native_password BY 'sbpass';<br>GRANT ALL ON sbtest.* TO 'sbtest'@'localhost';<br>FLUSH PRIVILEGES;

连接时显式指定认证插件：

sysbench --db-driver=mysql --mysql-user=sbtest --mysql-password=sbpass --mysql-plugin-dir=/usr/lib/mysql/plugin/ oltp_read_write ...

若仍报错，检查 mysql --version 和 sysbench 编译时链接的 MySQL client 库版本是否一致；不一致容易触发认证协议解析异常

用 `sysbench oltp_common` 准备数据时，`--tables=32` 和 `--table-size=1000000` 的实际影响是什么

这两个参数决定压测数据集规模，直接影响内存占用、IO 压力和索引构建耗时，不是“越大越好”。

--tables=32：生成 32 张结构相同的表（如 sbtest1 ~ sbtest32），提升并发线程间的数据隔离度，减少锁竞争；但超过 64 后，InnoDB 的 innodb_buffer_pool_instances 若未同步调高，反而引发内部 mutex 争用
--table-size=1000000：每张表插入 100 万行，默认主键自增 + 二级索引（k, c, pad）；单表约占用 200–300MB 磁盘空间，全量加载后 Buffer Pool 至少需预留 8GB 以上才不易频繁淘汰
常见误操作：在 4GB 内存机器上设 --tables=64 --table-size=500000，导致 prepare 阶段卡死或 OOM，应先用 --threads=1 小步验证

运行 `sysbench oltp_read_write` 时，`--time=300` 和 `--events=0` 必须同时用吗

不用。二者控制压测终止条件，互斥使用，选其一即可；混用会导致行为不可控。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

--time=300：固定运行 300 秒，适合评估稳态吞吐（QPS/TPS）和延迟分布；推荐用于服务器级性能摸底
--events=0：表示不限制事件数，配合 --time 才有意义；单独设 --events=0 会无限执行直到手动 Ctrl+C
真正要注意的是 --rate：设了它（如 --rate=100），sysbench 会强行限速到每秒 100 个事务；此时即使 --time=300，实际 QPS 也被钉死，无法反映数据库真实吞吐上限

压测结果里 `queries:` 和 `transactions:` 差三倍，为什么

因为 oltp_read_write 每个事务默认包含 3 条语句（1 UPDATE + 1 SELECT + 1 INSERT），queries 统计所有 SQL 执行次数，transactions 统计 COMMIT 次数。

看吞吐能力，盯 transactions/sec（即 TPS），它对应业务侧“每秒完成事务数”；queries/sec 更多反映 IO 或网络负载强度
如果你改了 --mysql-table-engine=rocksdb 或加了 --skip-trx，事务模型变化，这个比例会变；不要拿不同配置下的 queries/sec 直接比性能
延迟字段中 95th percentile 比平均值更有参考价值——MySQL 在大压力下尾部延迟跳升很快，平均值容易掩盖毛刺

实际跑满吞吐的关键不在参数堆叠，而在观察 SHOW ENGINE INNODB STATUS\G 里的 SEMAPHORES 和 TRANSACTIONS 部分：一旦看到大量 wait array 或 lock wait，说明瓶颈已从 CPU/IO 转向锁或 LRU latch，再加线程只会让 TPS 下滑。