硬件评估核心是先确定活跃数据量和业务类型再反推配置，配错innodb_buffer_pool_size比选错服务器更致命。
直接说结论：硬件评估不是查CPU几核、内存多大，而是先搞清“活跃数据量”和“业务类型”，再反推配置。配错 innodb_buffer_pool_size 比买错服务器更致命。
怎么算 innodb_buffer_pool_size 才不翻车
它不是数据库总大小 × 0.7，而是“高频访问的数据量 × 1.2～1.5”，且必须留足系统内存给 OS 和后台线程。
- 先估算活跃数据：比如订单库中近30天的记录、用户登录表最近7天的 token，用
SELECT COUNT(*) FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 30 DAY)+ 行平均长度粗估体积 - 设上限：不超过物理内存的 75%，超过 80% 极易触发
swappiness交换，一次 swap 延迟可能飙到 100 倍 - 验证是否够：查
SHOW STATUS LIKE 'Innodb_buffer_pool_reads'，持续 > 50 次/秒说明磁盘读太多，该扩容了 - 别忽略实例数：设
innodb_buffer_pool_instances为 CPU 核心数（如 16 核就设 16），否则高并发下缓冲池锁争抢严重
CPU 选多核还是高主频，取决于你跑的是 OLTP 还是 OLAP
同一套 16 核 CPU，电商下单和报表导出的体验可能完全不同——MySQL 对 CPU 的压法根本不一样。
- OLTP（如支付、登录）：单条 SQL 快才是关键，主频 > 核心数。推荐基础频率 ≥ 3.2 GHz，睿频 ≥ 4.0 GHz（如 Intel Xeon Gold 6330）
- OLAP（如月报、宽表 JOIN）：天然并行，核心越多越快。可选 32 核但基础频 2.8 GHz 的型号，省预算还更稳
- 开发机别堆核：4 核 8 线程（如 i5-12400F）足够本地压测，再多核心在单机 MySQL 里基本闲置
- 多路服务器必开 NUMA：否则跨节点访存慢 30% 以上，加配置
innodb_numa_interleave=1或用numactl绑定
SSD 不是插上就能快，I/O 参数必须对得上盘的真实能力
换 NVMe 后 QPS 没涨反跌？大概率是 MySQL 还在按 SATA 节奏干活，没“认出”这块盘。
- 先测真实 IOPS：
sudo fio -name=randread -ioengine=libaio -rw=randread -bs=4k -direct=1 -size=1G -runtime=60 -time_based -group_reporting - 再设参数：把实测随机读 IOPS 的 70% 填进
innodb_io_capacity，200% 填进innodb_io_capacity_max - 机械盘或入门 SSD：直接设
innodb_io_capacity=200、innodb_io_capacity_max=400，设太高会写放大 - 企业级 SSD 必须开
innodb_flush_method=O_DIRECT，否则 OS 缓存和 InnoDB 缓冲池双重缓存，浪费内存还增加一致性风险
max_connections 不是越大越好，每个连接都在吃资源
调到 10000 不代表真能扛住 1 万并发——每个连接背后都占内存、抢 CPU 上下文、争锁。
- 内存消耗：每个连接默认约 2 MB（含排序缓存、临时表等），1000 连接 ≈ 2 GB
- 线程成本：超 500 并发后，线程创建/销毁开销会明显上升，建议配合
thread_cache_size缓存复用 - 监控实际负载：
SHOW STATUS LIKE 'Threads_connected'看当前连接数，SHOW STATUS LIKE 'Threads_created'看线程创建频次 - 别只调
max_connections：应用层必须配连接池（如 HikariCP），避免短连接风暴打穿数据库
最容易被忽略的点是：硬件瓶颈往往是连锁反应。内存不够 → 频繁刷脏页 → I/O 崩了 → CPU 等待 I/O → 表面看是 CPU 高，其实根子在 buffer pool 配小了。所以别急着升级 CPU，先盯住 Innodb_buffer_pool_reads 和 Threads_running 这两个指标。
