sysbench是MySQL最直接的性能验证入口，需创建测试库、准备数据、调优MySQL配置（buffer_pool_size、max_connections、log_file_size）、使用socket连接、同步监控IO/CPU/锁等待。
用 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 配置无效。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
避免用 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。
