压测前须手动创建sbtest库和sbuser用户并授权，sysbench不会自动建库；prepare阶段需调优线程数、表大小、存储引擎及日志参数以提速；压测时须监控连接数、缓冲池命中率、锁等待及磁盘io；缓存预热须在run阶段同步进行，覆盖真实业务sql并计入压测报告。
压测前必须手动创建库和用户，sysbench 不会自动建库
很多人跑 sysbench oltp_read_write --db-driver=mysql prepare 直接报 Unknown database 'sbtest'，不是工具问题，是 MySQL 默认禁止命令行自动建库。必须提前登录 MySQL 手动执行：
CREATE DATABASE sbtest CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;CREATE USER 'sbuser'@'localhost' IDENTIFIED BY 'pass123';GRANT ALL ON sbtest.* TO 'sbuser'@'localhost';
后续所有 sysbench 命令都得显式带上 --mysql-db=sbtest 和 --mysql-user=sbuser，别依赖默认值。漏掉任意一项，prepare 阶段就会卡住或失败。
prepare 阶段慢？关 autocommit + 开多线程 + 换小表
默认单线程插入 100 万行/表，I/O 和事务开销拉满，生成 4 张表可能耗时十几分钟。这不是数据库慢，是压测脚本没调优：
- 加
--threads=8（按 CPU 核数设，别超 16） - 加
--mysql-storage-engine=innodb显式指定引擎 - 把
--table-size=100000（10 万）代替默认 100 万，配合--tables=4，总数据量相当但预热更快 - 测试环境可临时关日志刷盘：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;和SET GLOBAL sync_binlog = 0;（压完务必改回！）
这些调整能让 prepare 时间从分钟级降到秒级，且更贴近大促前快速验证配置变更的节奏。
压测要模拟真实瓶颈，不能只看 QPS 上升了没
大促真正垮掉的时候，往往不是 CPU 100%，而是连接池耗尽、锁等待堆积、Buffer Pool 命中率暴跌到 70% 以下。所以压测时必须同步盯这些指标：
- 用
mysqladmin extended-status -r -i 1 | grep -E "Threads_connected|Innodb_buffer_pool_hits|Innodb_row_lock_waits"实时观察 - 每 10 秒查一次
show processlist，重点找Waiting for table metadata lock或Locked状态 - 用
iostat -x 1看%util是否持续 >95%，await是否突增 —— 这说明磁盘成了瓶颈
如果 QPS 到 2000 就上不去了，但 CPU 才 40%，那八成是锁或 IO 卡住了，而不是数据库“性能差”。
缓存预热不能等大促开始才做，得在压测阶段就介入
懒加载缓存在大促第一波流量下极易击穿。正确做法是：在 sysbench 压测 run 阶段启动后，立刻用脚本批量请求热点 key，比如商品详情、订单状态接口，把 Redis 和 MySQL 查询结果一起灌进缓存。
更关键的是，预热 SQL 要跟业务一致：
- 别只预热
SELECT * FROM product WHERE id = ?，还得覆盖SELECT * FROM order_history WHERE user_id = ? ORDER BY create_time DESC LIMIT 20这类带排序分页的真实查询 - 用
EXPLAIN确认这些语句走的是预期索引，否则预热进去的也是低效结果 - 预热数据量建议为预计峰值 QPS × 2 秒，比如峰值 5000 QPS，就预热 1 万条不同参数的请求
预热动作本身要计入压测报告——它不是准备步骤，而是稳定性保障的一部分。漏掉这点，压测再高分，上线头一分钟照样雪崩。
