核心思路：先评估业务负载类型、数据量、并发、SLA，再匹配 CPU / 内存 / 磁盘 / 网络，最后区分物理机、虚拟机、容器、云数据库选型，不要上来直接堆硬件。
一句话原则：数据库绝大多数场景是内存优先，其次磁盘 IO，CPU 看计算压力。
一、第一步：明确业务需求（选型前置）
1. 业务类型
OLTP（交易型：MySQL/PostgreSQL/OpenGauss）：高并发、大量短查询、频繁随机读写。瓶颈一般在内存、磁盘随机 IO。
OLAP（分析型：ClickHouse、Doris、Greenplum）：大批量扫描、聚合、大查询。瓶颈在CPU、磁盘吞吐、带宽。
混合负载 HTAP：资源隔离要求高，建议分开部署或用支持资源组的数据库。
2. 核心指标收集
3. 高可用架构先行
先确定架构，再选机器：
单机：测试、非核心，不推荐生产
主从 / 一主多从：中小业务，读分离
分布式集群：海量数据、高可用、分片（分库分表、原生分布式）
架构会直接决定需要多台服务器，不是单台配置。
二、硬件参数选型（物理机 / 虚拟机）
✅ 内存（最重要）
数据库会把热点数据、索引尽量放内存。
OLTP：内存 ≥ 热点数据 + 索引大小。如果热点数据 100G，内存尽量配 128G 以上。
经验：
小业务：16G/32G
中等业务：64G~128G
核心交易：256G/512G
内存不够会大量刷磁盘，性能断崖下跌；内存过大成本上升，要平衡。
✅ CPU
OLTP：单核性能优先，核心数适中。数据库事务是串行化较多，不要盲目堆大量低频核。优先高主频。
OLAP：多核优先，越多越好，计算并行。
参考：
小业务：4~8 核
中高并发 OLTP：16~32 核
OLAP：32 核起步，64/128 核
信创场景（鲲鹏 / 飞腾）：注意单核算力等效 x86，不能直接按核数对标。
✅ 磁盘（IO 是第二大瓶颈）
区分两个指标：随机 IOPS（OLTP）、顺序吞吐（OLAP / 备份）
介质优先级：
NVMe SSD > SATA SSD > SAS机械 > SATA机械生产 OLTP：优先 NVMe SSD，不能用普通机械盘做主库
冷数据、备份、归档：机械盘
容量计算： 总容量 = 业务数据 + 索引 + binlog/wal 日志 + 临时文件 + 备份空间 + 冗余（20%~50% 预留）
阵列：
数据库数据盘：RAID10（兼顾性能 + 安全）
日志盘（binlog/WAL）：独立 SSD，RAID1/RAID10，日志盘尽量和数据盘分离
坑：只看容量不看 IOPS，很多云盘低 IOPS，高并发直接卡死。
✅ 网络
单机主从：万兆网卡 (10Gbps) 起步，核心业务 25G
分布式集群（分片、多副本）：25G/100G，内网低延迟
注意：跨机房主从会有延迟，RPO 很难做到 0。
三、部署形态选择
1. 自建物理服务器
适合：大流量、信创、长期稳定、预算充足，需要极致性能可控 优点：性能稳定，无虚拟化损耗；缺点：运维重，扩容慢，一次性投入高。
2. 虚拟机（VMware/KVM）
适合：中小业务，资源隔离，方便克隆备份 注意：内存不要超分配，磁盘直通 / 独立存储，不要和其他高 IO 业务混部。
3. 容器 Docker/K8s
适合：测试、CI/CD、轻量非核心库 生产数据库容器坑多：IO 隔离、磁盘持久化、延迟、高可用复杂；核心 OLTP 不建议直接容器化，除非使用云原生数据库存储。
4. 云托管数据库（RDS/CloudDB）
适合：快速上线、不想运维底层，中小业务 优点：自动备份、主从切换、补丁；缺点：成本随流量上涨，底层硬件不可控，有云厂商锁。
信创项目：国产服务器 + OpenGauss / 达梦 / 人大金仓，要注意 ARM 架构适配，内存带宽、磁盘 IO 实测，不能只看理论参数。
四、分场景参考配置（快速参考）
仅参考，必须结合你实际 QPS 和数据量
场景 1：测试 / 开发库
CPU：4 核
内存：16G
磁盘：500G SSD
部署：虚拟机
场景 2：中小业务 OLTP（QPS 几千，数据几十 G）
CPU：8~16 核
内存：64G
磁盘：NVMe SSD，RAID10，独立日志盘
架构：一主一从
场景 3：核心交易 OLTP（QPS 上万，数据 100~500G）
CPU：24~32 核，高主频
内存：128G~256G
磁盘：NVMe SSD，数据盘 + WAL 日志盘分离，RAID10
网卡：10G+
架构：一主多从 + 自动故障切换
场景 4：OLAP 分析库（报表、数仓）
CPU：32~64 核
内存：256G 起步
磁盘：大容量 SSD 或高速对象存储，看重顺序吞吐
架构：多节点集群
五、避坑清单
❌ 只看磁盘容量，忽略 IOPS：数据库 90% 性能问题是磁盘 IO 瓶颈
❌ 内存小于热点数据：大量 page swap，性能暴跌
❌ 日志和数据共用一块盘：日志刷盘阻塞业务
❌ 虚拟化超配内存、CPU 争抢：高峰期抖动
❌ 分布式集群用千兆网卡：副本同步卡死
❌ 直接用容器跑核心生产数据库
❌ 只按平均 QPS 评估，忽略业务峰值（秒杀、报表定时任务）
六、验证与容量规划建议
上线前压测：模拟峰值 TPS/QPS，观察 CPU、内存、磁盘 IO、swap、慢查询
监控预留：CPU 日常 < 70%，内存预留，磁盘使用率预警阈值 80%
预留扩容通道：要么云库弹性扩容，要么预留服务器 / 存储资源
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢