MySQL调优先别动参数，我选硬件只看三个指标

数据库一慢，很多人的第一反应是打开配置文件改参数。把 innodb_buffer_pool_size 往大调，把 max_connections 翻倍，再重启一遍。折腾半天发现查询还是卡。问题往往不在参数，在于机器本身就没选对——参数能把硬件吃干榨净，但变不出硬件里没有的东西。

我见过不少这样的配置：一台 16G 内存的机器跑着 50G 热数据的库，buffer pool 设到 12G 就顶天了，剩下的查询全走磁盘。这时候你调什么参数都没用，缺的是内存。选型这件事得在调优之前做。

内存先算热数据，别按总数据量买

最容易被买错的就是内存。有人看数据库文件 200G，直接买 256G 内存的机器，其实没必要。InnoDB 的 buffer pool 只缓存热数据，冷数据放磁盘上完全能接受。

怎么估热数据？看你的业务表。一个日活几千的站点，真正频繁读写的往往就是用户表、订单表那几张，加起来可能 20G 到 30G。这种规模配 64G 内存，buffer pool 给到 48G 左右，命中率就能稳在 99% 以上。

按我的经验，单机 MySQL 内存和热数据的比例保持在 2:1 到 3:1 比较舒服。热数据 20G，配 64G；热数据 60G，那就得上 128G 以上。内存买小了，后面只能换机器，数据迁移的停机成本比内存差价高得多。

SSD 的 IOPS 比容量更值得花钱

机械盘跑 MySQL 现在基本不用考虑了。真正要挑的是 SSD 的随机读写能力。顺序读写快不代表数据库快，InnoDB 刷脏页、写 redo log 全是随机小 IO。

选机器的时候看清楚是 SATA SSD 还是 NVMe。SATA SSD 的随机 IOPS 通常在一两万这个量级，NVMe 能到几十万。写入密集的业务，比如订单系统、日志表，用 NVMe 的延迟差别能直接感觉到。

容量方面，别把数据盘塞满。SSD 用到 80% 以上性能会掉，留出 20% 到 30% 的余量。100G 的库，配 200G 的盘更稳妥。

主频和核心数，单机场景先看主频

这一点很多人搞反。看到 32 核 64 核就觉得性能强，实际上 MySQL 单条查询只用一个核。核心多对高并发有帮助，但单条复杂查询的响应速度，看的是单核主频。

一个跑报表的库，几条大查询就能把 CPU 跑满，这时候 3.0GHz 的四核可能比 2.0GHz 的十六核更快。反过来，如果是大量短连接的小查询，核心数才有意义。

我给的建议是：中小站点先保证单核主频在 2.5GHz 以上，核心数 8 到 16 核够用。真正上到 32 核以上的场景，通常是分库分表之前的大单体，或者读写分离里的主库。

带宽这块容易被忽略。主从复制、备份传输都吃带宽。20M 带宽对多数中小库够用，如果做异地备份或者数据量增长快，提前留出余量。像 马来西亚裸机云 XII 这种 E5-2683v4 双路、64G 内存、20M 带宽的独立服务器，月付 169 美元，跑一个中等规模的 MySQL 实例比较合适，吉隆坡机房对东南亚业务的延迟也友好。

什么时候该加机器，什么时候该改架构

硬件加到头了还是慢，就别再堆配置了。几个信号值得注意：

• 单表数据超过 2000 万行，查询开始明显变慢，考虑分表
• 写入 QPS 持续超过单机上限，读多写少的场景先做读写分离
• 备份窗口越来越长，影响正常业务，该考虑从库做备份

换我我会先花一个月看真实负载曲线。CPU 长期在 30% 以下、内存也没吃满，那问题在 SQL 和索引，加机器是浪费钱。反过来 CPU 和 IO 双双打满，参数也调过了，那就是硬件到顶，该升级了。

预算紧的话，先从 64G 内存加 NVMe 的独立服务器起步，月付一两百美元这个档位能覆盖大多数中小业务。等业务真的涨上来，再考虑上更高配的机器或者拆架构。别一上来就买顶配，也别在 16G 内存的机器上死磕调优。