8核16G的云服务器跑MySQL，听起来是个不小的配置，但实际表现如何，只有压测数据说话。同样的规格，磁盘类型不同、参数配置不同、并发模型不同，性能差距可能达到数倍。本文将以腾讯云标准型S5实例为例，完整演示如何用sysbench对MySQL进行压测，分析瓶颈所在，并给出一套经过验证的优化建议。
压测前的环境准备与基准配置
在进行压测之前，必须先固定好变量，否则测出来的数据没有可比性。首先是云服务器本身的选择：8核16G建议选择标准型S5或SA2实例，系统盘用云硬盘，数据盘建议单独挂载一块增强型SSD云硬盘，容量至少100G以上，这样能保证磁盘IO不受系统盘干扰。数据库版本建议使用MySQL 8.0，操作系统选择腾讯云官方的TencentOS或CentOS 7.9。
MySQL安装完成后，先记录一份默认配置作为基线，然后再逐步调优。基线参数可以参考下面这份：
[mysqld] # 基础配置 port = 3306 character_set_server = utf8mb4 # InnoDB核心参数 innodb_buffer_pool_size = 10G innodb_log_file_size = 1G innodb_flush_log_at_trx_commit = 1 innodb_flush_method = O_DIRECT # 连接相关 max_connections = 2000 thread_cache_size = 64 table_open_cache = 4096 # 慢日志 slow_query_log = 1 long_query_time = 1
这里有几个关键点需要说明。innodb_buffer_pool_size是影响最大的参数，16G内存的机器，除去操作系统预留和MySQL自身开销，分配10G到12G给缓冲池是合理的。设置过小会导致大量磁盘读，设置过大则可能触发OOM。innodb_flush_method设置为O_DIRECT可以避免操作系统页缓存与InnoDB自身的缓冲池双重缓存，减少内存浪费。
另外，压测客户端不能和MySQL部署在同一台机器上，否则压测程序本身会抢占CPU和IO资源，导致数据失真。建议再开一台4核8G的机器专门跑sysbench，两台机器处于同一可用区、同一内网，避免网络延迟干扰测试结果。
使用sysbench进行多场景压测
sysbench是最常用的MySQL压测工具，安装简单，脚本丰富。以yum为例，安装epel源后直接安装即可：
yum install -y epel-release yum install -y sysbench
压测分两个阶段：数据准备阶段和压测执行阶段。先准备一张100万行的测试表：
# 准备数据 sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host=10.0.0.11 --mysql-port=3306 \ --mysql-user=sbtest --mysql-password=Test@123456 \ --mysql-db=sbtest --tables=10 --table-size=1000000 \ prepare # 压测：8线程起步，逐步加大并发 sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host=10.0.0.11 --mysql-port=3306 \ --mysql-user=sbtest --mysql-password=Test@123456 \ --mysql-db=sbtest --tables=10 --table-size=1000000 \ --threads=16 --time=300 --report-interval=10 \ --percentile=95 run
建议按照并发数递增的方式做一轮完整测试，比如依次测试16、32、64、128、256线程，每个档位持续5分钟，记录TPS、QPS、95分位延迟三个指标。在一台配置了增强型SSD云盘的8核16G实例上，典型结果大致是：16线程时TPS约1200，延迟3毫秒左右；64线程时TPS达到峰值约2400；继续加到128线程以上，TPS不再上升甚至下降，95分位延迟迅速攀升到30毫秒以上。这说明系统的瓶颈点已经出现，盲目增加并发只会让排队越来越严重。
压测过程中要同步观察服务器状态。重点盯三类指标：一是top里的CPU使用率，如果us占比接近100%而iowait很低，属于CPU瓶颈；二是iostat -x 1里的磁盘_util和await，如果_util长期超过90%，属于IO瓶颈；三是MySQL内部的SHOW ENGINE INNODB STATUS输出，关注行锁等待和缓冲池命中率。如果缓冲池命中率低于99%，说明数据集已经超出内存容量，此时优化参数收益有限，要么扩内存，要么对数据和索引做精简。
常见瓶颈分析与优化建议
根据压测中暴露的问题，优化可以从四个层面入手。
第一是存储层。云硬盘的性能上限是压测中最常见的隐形瓶颈。普通云硬盘的随机读写IOPS只有几千，而增强型SSD云硬盘可以按容量线性提升IOPS，100G以上大约能到6000到1万以上。如果预算允许，也可以考虑腾讯云的极速型SSD云硬盘，它提供接近本地盘的性能。另外注意innodb_flush_log_at_trx_commit参数：默认值1保证每次事务提交都刷盘，最安全但IO压力大。如果业务允许丢失1秒左右的事务（比如日志类、统计类场景），可以设置为2，配合sync_binlog=100之类的取值，IO吞吐能明显提升，但如果设为0则风险过高，不建议生产使用。
第二是连接与线程层。很多应用的问题在于连接数管理混乱：每个请求都新建连接，导致Threads_created持续增长，线程创建销毁的开销会大量消耗CPU。正确做法是在应用侧使用连接池，比如Java的HikariCP，把最大连接数控制在几百以内，同时MySQL端设置thread_cache_size让空闲线程复用。压测时如果发现Threads_created / Connections的比值偏高，就说明线程缓存不够或者连接没有复用。
第三是SQL与索引层。压测中如果出现大量行锁等待，通常不是MySQL的问题，而是SQL写法问题。热点行更新、没有索引导致的全表扫描加锁、大事务持有锁时间过长，都是典型原因。治理手段包括：给WHERE条件建合适的索引、把大事务拆小、对热点账户类数据采用队列缓冲后批量更新。开启慢查询日志并结合pt-query-digest分析，通常能快速定位TOP问题SQL。
第四是架构层。单机8核16G的能力终究有上限。当读多写少时，加一主一从的读写分离就能让读性能近乎翻倍；写入实在扛不住时，可以考虑按业务拆库，或者直接评估迁移到腾讯云数据库MySQL（云数据库TDSQL-C MySQL版），让托管服务负责高可用和备份，自己专注业务优化。压测数据最大的价值，就是告诉你当前架构距离极限还有多少余量，从而在业务增长前提前规划扩容路径，而不是等线上出事再仓促应对。