OLTP场景优先多核CPU（如16核以上），OLAP则侧重高主频与多核兼顾；内存按热数据量配置Buffer Pool（非全量），存储必须用NVMe SSD并隔离日志路径，网络带宽与连接数需按峰值余量规划。
高并发读写对数据库服务器不是单纯“堆配置”就能解决的问题，关键在于让CPU、内存、存储、网络四类资源协同匹配业务负载特征，避免单点瓶颈。选型要从场景出发，而不是从参数表出发。
看业务类型定CPU核心与主频策略
OLTP类高并发（如订单、支付、秒杀）本质是大量短平快SQL并行执行，优先选多核CPU，而非高频单核。8核起步是实用下限，16核以上更适合日均请求超50万的系统。例如Xeon Platinum或EPYC 7543这类支持PCIe 4.0和大容量内存通道的型号，既能扛住连接线程压力，又能支撑NVMe盘的高吞吐。OLAP混合场景（如带实时报表的后台）则需兼顾——多核保障并发，主频不低于3.2GHz以缩短复杂查询耗时。
- 4核以下只适合测试或QPS＜500的轻量应用
- 每增加1000并发连接，建议预留1–2个逻辑CPU核心
- 启用innodb_read_io_threads和innodb_write_io_threads，设为CPU核心数的一半可提升I/O并行度
按数据热区规模配内存，不是按总量硬算
内存的核心作用是把频繁访问的数据和索引“钉”在缓冲池里。InnoDB Buffer Pool应覆盖热数据+热索引，而非全量数据。例如100GB数据中，若每天活跃访问集中在20GB用户表和5GB订单索引，那么24–32GB内存比盲目配64GB更有效。公式上，innodb_buffer_pool_size = 热数据量 × 1.2～1.5，再加OS与连接开销（每个连接约3–4MB）。
- 中小型（QPS 1k–5k）：16–32GB内存，Buffer Pool占70%左右
- 大型（QPS 1w+）：64GB起，需开启innodb_numa_interleave=ON防NUMA不均衡
- 避免设置过小导致Buffer Pool命中率＜85%，此时磁盘I/O会陡增
存储必须用低延迟SSD，且区分读写路径
机械盘在高并发下I/O响应动辄几十毫秒，而MySQL 8的Redo Log写入、Binlog刷盘、Buffer Pool刷新都依赖存储延迟。必须选NVMe SSD或高性能云盘（如阿里云ESSD PL3），随机读写IOPS需≥8000。更重要的是路径隔离：Redo Log和Binlog建议放在独立挂载点（甚至物理盘），避免与数据文件争抢队列。
- 数据盘容量 = 当前数据量 × 3（含日志、临时表、备份预留）
- 日志盘单独配置，大小建议≥数据盘的20%，使用O_DIRECT绕过页缓存
- 云环境优先选支持“多副本强一致”的云盘，降低主从同步延迟
带宽与连接数要留出真实余量
网络不是只看标称带宽，而是看实际吞吐是否匹配峰值流量。比如1Gbps理论值≈125MB/s，但MySQL复制、备份、应用读取共享该带宽。若主库每秒产生30MB Binlog，再叠加10个只读副本同步，带宽很容易打满。连接数也一样：max_connections设太高会吃光内存，设太低则连接池排队。合理值≈预估并发请求数 × 1.5（含后台线程、监控采集等）。
- 千级QPS建议1Gbps起步；万级QPS需10Gbps或负载分摊到多个节点
- 每连接内存消耗≈3–4MB，1000连接就需3–4GB额外内存
- 用performance_schema定期查threads_connected和Threads_running，动态调优
