别再乱买服务器了，选对主机配置才靠谱
最近帮朋友公司搭数据库环境，发现不少人还在凭感觉选主机配置。有人花大价钱买了高配CPU，结果内存不够用，查个报表卡得像老式DVD机；也有人图便宜选了小内存机器，跑着跑着MySQL直接崩了。其实主机配置怎么选，真不是看预算高低，而是要看你跑的是什么数据库、数据量多大、并发有多少。
先看数据库类型，不同系统需求差很多
比如你用的是MySQL这类关系型数据库，日常读写频繁，那就得重点考虑磁盘IO性能。SATA盘便宜，但上万条记录一查，响应慢得让人想砸键盘。换成SSD，尤其是NVMe SSD，查询速度能快好几倍。实际测试中，同样的查询语句，在SATA SSD上要800毫秒，换到NVMe可能只要180毫秒，用户体验差太多了。
要是跑的是MongoDB这种文档型数据库，数据经常随机读写，那内存就得给足。MongoDB靠内存缓存热点数据，内存不够就频繁访问磁盘，性能直线下降。建议内存至少是活跃数据集的1.5倍，不然你会发现服务器CPU利用率不高，但响应就是慢。
CPU不是越多越好，关键看使用场景
很多人觉得核心数越多越强，但数据库应用很多时候只用单线程处理查询。比如MySQL在执行复杂JOIN时，往往只能利用一个核心。这时候主频高的CPU反而更合适。一台16核2.1GHz的机器，可能还不如8核3.0GHz的跑得快。
当然也有例外。如果你做的是大数据分析，或者用PostgreSQL跑并行查询，那多核就有优势了。这时候可以看看支持并行执行的参数设置：
SET max_parallel_workers_per_gather = 4;
SET max_worker_processes = 16;这些配置只有在多核环境下才能发挥效果。
内存和Swap，别让系统自己挣扎
见过最离谱的情况是有人给数据库主机只配8GB内存，还开着Swap。一到晚上定时任务跑起来，内存耗尽开始用Swap，性能暴跌十倍。数据库对延迟敏感，一旦开始频繁换页，连接就会堆积，最终导致服务不可用。
建议把Swap关闭或设得很小，逼系统早点报错，而不是让它慢慢拖死。内存大小可以根据数据量预估：比如每天新增10万条记录，每条平均1KB，一年大概3.6GB，加上索引、连接池、操作系统开销，起步至少16GB，生产环境建议从32GB起配。
网络带宽容易被忽视，尤其在分库分表时
现在不少公司用主从复制、读写分离，主机之间靠网络同步数据。如果主机在网络高峰时段带宽打满，主从延迟可能达到几分钟。用户刚注册完，登录时从库还没同步到数据，提示“用户不存在”，这种问题定位起来特别头疼。
建议内部同步走独立网卡或内网通道，最低也要千兆网络。跨机房部署的话，务必测一下网络延迟，ping超过5ms就要警惕了。
实际配置参考，拿去直接用
下面是几个常见场景的配置建议，基于阿里云ECS规格调整：
小型业务（日活<1万）
CPU：4核
内存：16GB
磁盘：500GB NVMe SSD
适用：初创项目、测试环境
中型系统（日活1~10万）
CPU：8核（主频>2.8GHz）
内存：32GB
磁盘：1TB NVMe SSD
网络：1Gbps内网
适用：电商平台、会员系统
大型分析平台（数据仓库类）
CPU：16核以上
内存：64GB~128GB
磁盘：多块2TB SSD组RAID10
适用：BI报表、日志分析
主机配置不是越高越好，也不是越便宜越好。关键是匹配你的数据库 workload。上线前做一次压力测试，模拟真实访问场景，比啥都管用。别等到用户投诉了才想起来升级机器，那时候损失可就大了。