硬件评估核心是先确定活跃数据量和业务类型再反推配置，配错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 节奏干活，没“认出”这块盘。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 先测真实 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 这两个指标。