决策：服务器规格规划

正确的规格规划从负载画像（OLTP、数据仓库、混合）出发，需要找出真正的瓶颈（CPU、I/O 或 RAM）。黄金法则：频繁访问的数据集（工作集）必须能放入 RAM；先测量再扩展，并为突发负载预留余量。这棵决策树帮助你识别负载，并根据瓶颈选择资源和扩展方向（垂直/水平）。

你的负载画像是什么？

规格规划从负载开始，因为 OLTP 和分析型负载需要完全不同的资源配置。系统的主要工作是什么：大量小而快的事务（OLTP），带有大规模扫描和聚合的报表/分析（DWH），还是两者混合？如果不确定，需要先进行测量。

• OLTP — 大量小而短的事务（Web/应用）
• 分析 / 数据仓库（DWH）— 大规模扫描和聚合
• 混合负载，或者我不确定
• 我知道瓶颈在哪；应该垂直扩展还是水平扩展？

瓶颈在哪里：RAM、I/O 还是 CPU？

在 OLTP 中，应找出真正的瓶颈，而不是盲目增加资源。查看你的指标：是频繁访问的数据放不进 RAM 导致磁盘读取量高（RAM/I/O），磁盘延迟/IOPS 不足（I/O），还是数据已经在内存中但 CPU 饱和（CPU）？扩展错误的资源会浪费金钱和时间。

• 频繁访问的数据放不进 RAM；磁盘读取量高
• 数据在内存中，但磁盘延迟/IOPS 不足（写密集）
• 数据在内存中且磁盘正常，但 CPU 持续饱和

建议：先测量，再规划规格

凭猜测购买硬件，几乎总是得到错误的规格。负载画像和瓶颈来自真实的指标。规格规划不是猜测，而是由测量驱动的迭代。

建议：增加 RAM — 工作集必须能放入内存

OLTP 最关键的规则：频繁访问的数据和索引（工作集）必须能放入内存（buffer/cache）。如果放不下，每个查询都会访问磁盘，延迟激增，I/O 成为瓶颈。RAM 通常是回报最高的投资。

建议：加强 I/O 层（IOPS/延迟）

即使数据在内存中，在写密集负载（commit、WAL/redo/binlog、checkpoint）下，磁盘速度仍然是决定性因素。这里的问题不是容量，而是 IOPS 和延迟。错误的磁盘类别会让系统在 CPU/RAM 很快的情况下依然不堪重负。

建议：解决 CPU 瓶颈（先优化查询，再加核心）

如果数据在内存中、磁盘正常而 CPU 饱和，根本原因通常是低效的查询（糟糕的执行计划、缺失的索引、大量小查询）或过高的并发。在增加核心之前先降低负载，通常更便宜也更有效。

建议：分析/DWH — 吞吐量、并行度和水平扩展

数据仓库负载由少量重型查询组成，这些查询扫描并聚合大表。这里的优先级不是低延迟，而是高扫描吞吐量、并行度，通常还需要可水平扩展的架构。

通用原则：垂直 vs 水平 + 余量 + 先测量

如何扩展与扩展哪种资源同样重要。垂直扩展（更大的机器）简单，但有上限且存在单点故障；水平扩展（更多机器）可以扩展，但会增加复杂性。无论哪种情况，都要为突发负载预留余量，并用测量结果验证决策。