创建专用用户并指定认证插件可解决sysbench 5.7+连接MySQL 8.0的ERROR 1045；--tables和--table-size决定数据规模与资源消耗；--time与--events互斥；queries是SQL总数，transactions是事务数，比例为3:1；95th延迟比平均值更具参考价值。
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 必须同时用吗
不用。二者控制压测终止条件，互斥使用，选其一即可；混用会导致行为不可控。
-
--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 下滑。
