DigitalOcean以其简洁的控制台和透明的计费方式，成为不少个人开发者和中小团队部署服务的首选。但当你打算在一台Droplet上自建MySQL数据库时，心里难免打鼓：入门套餐那点内存够用吗？NVMe SSD磁盘的随机读写到底有多快？并发上来之后查询延迟会不会爆炸？这篇文章基于实际压测数据，把这些疑问逐一说清楚。
实例规格选择：内存是第一道分水岭
DigitalOcean的Droplet分为Basic、General Purpose、CPU-Optimized和Memory-Optimized几个系列。对MySQL这种内存密集型应用来说，CPU核数反而不是首要考虑因素，关键在于内存容量必须能装下工作数据集。原因很简单：InnoDB引擎的核心设计依赖缓冲池（buffer pool）来缓存热数据，一旦热数据超过内存，每次查询都要穿透到磁盘，性能会断崖式下跌。
实测中，1GB内存的基础款Droplet（1 vCPU）只分配约400MB给InnoDB缓冲池，跑一个500万行的测试表时，随机读QPS只有800左右，且延迟抖动明显。换成8GB内存的General Purpose机型后，同样的数据集全部驻留内存，QPS直接冲到11000以上，差距超过十倍。这个结果印证了一个经验法则：缓冲池大小至少要覆盖最活跃表的总数据量加索引大小，否则加CPU只是浪费钱。
另一个容易忽视的坑是swap。1GB机型在系统模板里默认可能带有swap分区，内存吃紧时MySQL被换出到磁盘，表现为查询延迟周期性地飙到几百毫秒。如果你观察到vmstat中si/so列持续不为零，基本可以判定缓冲池设大了，需要收缩innodb_buffer_pool_size或者升级机型。
磁盘IO实测：NVMe SSD并非想象中那么简单
DigitalOcean宣称所有Droplet都使用NVMe SSD存储，但不同套餐的磁盘吞吐和IOPS差异很大。基础款采用共享CPU，磁盘性能也受邻居影响；而General Purpose及以上系列配有独立NVMe存储，性能稳定得多。用fio做4K随机读写测试，基础款大约在1万到1.5万IOPS之间波动，而8GB的GP机型可以稳定输出4万IOPS以上。
对MySQL来说，磁盘性能直接决定了写放大场景下的表现。InnoDB有doublewrite机制，每次刷脏页实际会产生两倍写流量，加上redo log顺序写，一次事务提交触发的物理写入比想象中多。实测开启innodb_flush_log_at_trx_commit=1（最安全的持久化设置）后，基础款的写入TPS只有600上下，而把它改成2（每秒刷盘一次）后TPS翻了一倍多。这个参数怎么取舍要结合业务：资金类数据必须保持默认值1，日志类、统计类数据可以放宽到2换取吞吐。
# fio测试4K随机写，观察云盘真实IOPS
fio --name=randwrite --ioengine=libaio --rw=randwrite \
--bs=4k --numjobs=4 --size=2G --runtime=60 \
--group_reporting --filename=/tmp/fiotest
# sysbench OLTP压测，20并发线程
sysbench oltp_read_write --db-driver=mysql \
--mysql-host=127.0.0.1 --mysql-user=sbtest \
--mysql-password=xxx --tables=10 --table-size=1000000 \
--threads=20 --time=300 run需要注意的是，Droplet根磁盘的可用空间和机型绑定，无法单独扩容根盘。如果数据增长快，可以挂载Block Storage卷，但Block Storage走的是网络存储路径，延迟比本地NVMe高一个量级，不建议把高写入的MySQL数据目录放在上面。
小内存实例的my.cnf调优建议
默认安装的MySQL 8.0配置非常保守，缓冲池只有128MB，在云主机上几乎等于没调。对于1GB到2GB的小机型，推荐从下面这份配置起步，核心思路是压缩内存占用、控制连接数、减少不必要的功能开销：
[mysqld] # 缓冲池设为物理内存的40%到50%，给系统和连接留余地 innodb_buffer_pool_size = 512M innodb_buffer_pool_instances = 1 # redo log适当加大，减少检查点频率 innodb_redo_log_capacity = 512M # 每秒刷一次log，牺牲少量持久性换吞吐 innodb_flush_log_at_trx_commit = 2 # 1GB机型不要开双1加高性能模式，先保证稳定 max_connections = 100 innodb_flush_method = O_DIRECT # 关闭查询缓存（8.0已移除，若是5.7建议显式关闭） # performance_schema会吃100MB以上内存，小机器可关闭 performance_schema = OFF # 临时表大小限制，防止慢查询撑爆内存 tmp_table_size = 32M max_heap_table_size = 32M
其中innodb_flush_method = O_DIRECT很重要，它让InnoDB直接写磁盘而绕过操作系统页缓存，避免内存被双重缓存占用——在小内存实例上这部分浪费相当可观。关闭performance_schema则能一次性省下100多MB，对于只跑业务不需要细粒度监控的场景很划算。
调整完记得用mysqltuner.pl或pt-variable-advisor复查一遍，跑一周业务后再根据实际的Threads_connected、Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads的比值（命中率应保持在99%以上）做二次微调。
自建还是用托管数据库
DigitalOcean也提供Managed Database服务，底层同样是MySQL，但价格约为同配置Droplet的1.5到2倍。它换来的是自动备份、自动故障切换、只读节点和免运维。这笔账怎么算取决于团队情况：如果你只有一两个项目、数据量在几十GB以内、且有人能响应凌晨的告警，自建Droplet完全够用，灵活度还更高；如果数据库挂掉半小时就直接影响营收，托管方案的溢价买的是睡眠质量。
还有一种折中做法：业务初期用小Droplet自建，把备份通过mysqldump或xtrabackup推送到Spaces对象存储，等流量起来再平滑迁移到托管集群。整体来看，DigitalOcean的NVMe本地盘和透明的定价对自建MySQL相当友好，只要选对机型、配好参数，中小规模应用在它上面跑MySQL是完全可行的方案。
DigitalOcean DropletMySQL性能云服务器数据库优化修改时间：2026-09-03 22:03:06