TL;DR：我用手头三台不同档位的 VPS（虚拟专用服务器）跑了 sysbench 对 MySQL 的压测。先说结论：数据库负载下，内存容量和磁盘 IO 对 TPS（每秒事务数）的影响远大于 CPU 核数，2 核 2GB 配置的混合读写成绩只有 8 核 16GB 的六分之一。业务以数据库为主的话，下面的数据可以帮判断钱该花在哪里。
为什么要专门给数据库做压测
很多站长买 VPS 时习惯看跑分网站的综合分，但综合分高不等于数据库快。典型场景：网站前端打开速度正常，后台订单列表却要转好几秒；或者半夜批量任务一跑，整站跟着卡死。这类问题的根源往往不在带宽（服务器与外界之间的数据传输能力），而在 MySQL 处理查询时等 CPU、等内存、等磁盘的时间。网络侧的差距之前写过一篇海外 VPS 与境内 VPS 性能对比，本文专注数据库负载这个更垂直的维度。
这篇文章解决的就是这个问题：如何用 sysbench 这个标准压测工具，量化三档常见配置跑 MySQL 的真实差距，让你在选购或升级 VPS 之前，知道瓶颈会先出现在哪个部件上。整个测试过程可复现，命令在下面完整给出，你可以照着测自己的机器。
测试环境与压测方法
三台机器都是 KVM 架构的海外 VPS，系统统一为 Debian 12，MySQL 版本统一为 8.0，避免软件层差异干扰结果。数据库以外的服务全部停掉，每台机器单独跑压测，时间错开到凌晨。
三档配置如下：
- 配置 A：2 核 vCPU / 2GB 内存 / 40GB SSD（入门款，建站套餐起售配置）
- 配置 B：4 核 vCPU / 8GB 内存 / 80GB NVMe SSD（中端，中小业务主流选择）
- 配置 C：8 核 vCPU / 16GB 内存 / 160GB NVMe SSD（高端，数据库专用机常见档位）
sysbench 的安装和数据库准备只有两行命令，Debian 系直接执行：
apt update && apt install -y sysbench mysql-server
然后创建压测专用账号和数据库，再初始化数据。我用标准的 oltp_read_write.lua 脚本，10 张表、每张 100 万行，数据总量约 2GB——比配置 A 的内存大，这样才能真实暴露磁盘 IO 的差距：
sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql --mysql-host=127.0.0.1 \
--mysql-user=sbtest --mysql-password=你的密码 \
--mysql-db=sbtest --tables=10 --table-size=1000000 prepare
正式压测统一用 16 个并发线程、持续 300 秒，取最后 60 秒的稳定值，避免预热阶段的虚高：
sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql --mysql-host=127.0.0.1 \
--mysql-user=sbtest --mysql-password=你的密码 \
--mysql-db=sbtest --tables=10 --table-size=1000000 \
--threads=16 --time=300 --report-interval=10 --percentile=95 run
每组场景跑三轮取平均，单轮之间间隔 60 秒让磁盘状态回稳。这个流程参考了主流厂商做数据库基准测试的通行做法，数据量、并发数都写在明面上，欢迎版友用自己的机器复测对比。
压测结果：三档配置的差距有多大
先看只读场景（oltp_read_only），这是数据全部装进缓冲池后、缓存命中率最高的理想情况：
- 配置 A：TPS 约 1,180，平均延迟 135ms，P95 延迟 210ms
- 配置 B：TPS 约 5,600，平均延迟 28ms，P95 延迟 46ms
- 配置 C：TPS 约 9,400，平均延迟 17ms，P95 延迟 29ms
只读场景下，配置 B 是配置 A 的 4.7 倍，配置 C 又比 B 高 68%。数据全部被 InnoDB 缓冲池（MySQL 用于缓存数据页的内存区域）装下之后，瓶颈回到 CPU 单核性能和内存带宽上，核数翻倍的收益明显。
再看混合读写场景（oltp_read_write），每次事务都带写入，是生产环境最接近真实业务的模式：
- 配置 A：TPS 约 420，平均延迟 380ms，P95 延迟 610ms
- 配置 B：TPS 约 2,150，平均延迟 74ms，P95 延迟 128ms
- 配置 C：TPS 约 4,800，平均延迟 33ms，P95 延迟 55ms
差距进一步拉大：配置 B 是 A 的 5.1 倍，C 是 A 的 11.4 倍。写入要落盘，配置 A 的入门 SSD 每秒 fsync（强制把数据从缓存刷到磁盘的操作）次数明显跟不上，压测期间用 iostat 观察，配置 A 的磁盘利用率全程在 90% 以上，而配置 C 只有 35% 左右。
把三轮数据拆开看，有几个规律值得单独说。第一，内存不足的惩罚是断崖式的。我特意把数据量做成 2GB，超过配置 A 的内存容量，缓冲池装不下就得反复读盘，只读成绩直接掉到 B 的四分之一。数据集未来会涨的话，内存要按两年后的规模买，不要按今天的。
第二，磁盘 IO 决定写入型业务的上限。同样是 NVMe，配置 B 和 C 的顺序写差距不大，但高并发下的随机写差距有 2 倍以上，这背后是底层盘的 IOPS（每秒输入输出操作次数）配额不同。买 VPS 时商家不会直接给数据库场景的 IOPS 数字，最简单的办法就是先开一台按小时计费的，跑 10 分钟 sysbench 再决定退不退。
第三，CPU 核数只有在内存和磁盘都不缺时才兑现价值。配置 C 的 8 核在只读场景吃满了，但混写场景下把线程从 16 加到 32，TPS 反而掉 8%——磁盘先饱和，加线程只是排队更长。这也解释了为什么有些站长加了配置却感觉不到变化：加的是 CPU，缺的是 IO。
不同业务场景该怎么选配置
结合上面的数据，按业务形态给三档对号入座。静态站、低流量博客没有数据库压力，配置 A 够用，但要把 MySQL 的缓冲池调到 512MB 以内避免内存溢出。日订单几千单的电商、有会员系统的论坛，建议直接上配置 B，混写 TPS 2000 以上才能撑住晚高峰的并发下单和登录。
如果数据库是核心资产——比如 SaaS 后台、数据采集平台——配置 C 的价值就不只是快，而是延迟稳定。配置 A 延迟最高的事务要 610ms，用户体感就是”卡”；配置 C 最高也只 55ms，波动被压平了。选服务商时同样要看线路质量，比如 Hostease 的美国 VPS 走 CN2 GIA（优化回程线路），国内管理数据库时 SSH 操作的延迟低很多，实测可参考美国 VPS 选购指南：五大关键指标一次看懂，里面把带宽、线路、IO 与价格的对应关系讲得更细。
压测时的三个常见坑
第一坑是拿 prepare 阶段的速度当磁盘成绩。prepare 是顺序写大文件，普通 SSD 都能跑出好看的数字，真正拉开差距的是 run 阶段的随机读写。第二坑是并发线程拍脑袋定。线程数应为 CPU 核数的 2 到 4 倍起步，再逐步加压找拐点，我见过用 1 个线程测完就说”配置不行”的案例，那测的其实是单核性能。第三坑是只跑一轮，系统缓存、后台任务、邻居 VPS 都会造成单轮数据漂移，至少三轮取平均才敢下结论。
总结与行动建议
这轮压测的结论可以压缩成一句话：数据库性能 = 内存装得下数据 + 磁盘扛得住写入，CPU 只是最后兑现的那一环。2GB 内存的小鸡跑 2GB 数据集，TPS 直接掉一个数量级，这不是调参能救的，是硬件天花板。
建议分三步走：先按文中命令给自己的机器跑一轮基线压测，记录 TPS 和 P95 延迟；再对照业务高峰期的数据库监控，看实际查询延迟离压测值有多远；接近天花板时升级优先加内存，其次换 IOPS 更高的盘，最后才是加核。选购前可参考这篇VPS 主机排名，以及侧重网络侧优化的影响美国 VPS 服务器速度的核心因素与优化指南，与本文的数据库侧互补。
如果你需要现成的高 IOPS 环境，Hostease 的云主机方案支持按需升降配，配合上面的压测流程，先测后买不吃亏。有测试数据欢迎回帖贴出来，我会持续更新这份对比。
