用 sysbench 快速启动 MySQL 基准压测
不用写 SQL 脚本、不依赖业务数据，
sysbench是最直接的 MySQL 性能验证入口。它内置
oltp_read_write等标准化测试模型，能快速暴露连接数、TPS、延迟等瓶颈。
常见错误是直接跑默认参数——
sysbench 1.0+默认使用
--threads=1和极小表规模，结果毫无压力，根本测不出真实负载。 先创建专用测试库：
CREATE DATABASE sbtest CHARACTER SET utf8mb4;准备 8 张 100 万行的表：
sysbench oltp_read_write --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=xxx --mysql-db=sbtest --tables=8 --table-size=1000000 prepare运行时至少启用 16 线程并持续 300 秒：
sysbench oltp_read_write --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=xxx --mysql-db=sbtest --tables=8 --table-size=1000000 --threads=16 --time=300 --report-interval=10 run
MySQL 配置必须调优，否则压测结果失真
默认
my.cnf是为低负载设计的，压测时若不改关键参数，会立刻卡在
InnoDB buffer pool或连接等待上，测出来的是配置缺陷，不是 MySQL 本身能力。
重点改三项：
innodb_buffer_pool_size设为物理内存的 50%–70%，低于 2G 会导致频繁刷盘；
max_connections至少设为压测线程数的 2 倍（比如
--threads=32就不能低于 64）；
innodb_log_file_size建议 ≥1G，小日志文件会强制频繁 checkpoint，掩盖真实 IO 能力。
改完必须重启 MySQL：
systemctl restart mysqld，仅 reload 配置无效。
避免用 localhost 连接导致 TCP 栈干扰
在本机用
--mysql-host=127.0.0.1会走 TCP/IP 协议栈，引入内核网络层开销，尤其高并发下可能被
net.core.somaxconn或连接队列丢包干扰，测的不是数据库而是 Linux 网络栈。
正确做法是强制走 socket 文件：
确认 MySQL 的socket路径：
mysql -uroot -p -e "SHOW VARIABLES LIKE 'socket';"，通常为
/var/lib/mysql/mysql.sock； sysbench 中用
--mysql-socket=/var/lib/mysql/mysql.sock替代
--mysql-host和
--mysql-port； 此时连接绕过 TCP，延迟更稳，结果更贴近纯数据库吞吐能力。
监控必须同步抓取，单看 sysbench 输出会漏关键瓶颈
sysbench只输出 TPS/QPS/latency，但无法告诉你慢在哪：是磁盘 IO 拖累？CPU 跑满？还是 InnoDB 行锁冲突？
压测同时必须开三个终端盯住：
MySQL 内部状态：mysqladmin -uroot -p extended-status -r -i 1 | grep -E "Threads_connected|Innodb_row_lock_waits|Innodb_buffer_pool_wait_free"系统 IO 压力：
iostat -x 1看
%util和
await，超过 90% 或
await > 20ms就是磁盘瓶颈； CPU 与上下文切换：
vmstat 1关注
cs（context switch）值，若持续 > 50000，说明线程争抢严重，需调低
--threads或查锁。
真正难的不是跑起来，是把
sysbench数字和
show engine innodb status、
iostat、
perf top对上号——多数人卡在这一步，只信 TPS，不信背后那一堆 wait event。
