AWS新手疑问：高性能数据库为何选内存优化型EC2而非存储优化型？

高性能数据库（尤其是OLTP这类低延迟要求的场景）的核心痛点是尽可能降低数据访问延迟，内存优化型和存储优化型EC2的设计目标完全匹配不同的瓶颈场景，这就是为什么前者更受推荐：

• 数据库的热数据访问逻辑决定了内存是核心瓶颈
  绝大多数高性能数据库（比如MySQL、PostgreSQL）会把高频访问的热数据全量缓存到内存中，日常查询优先从内存读取，只有处理冷数据或持久化写入时才会触发磁盘IO。内存越大，缓存命中率越高，需要碰磁盘的概率就越低，整体延迟也就越可控。存储优化型EC2的高IOPS优势，在大部分请求都走内存的场景下根本发挥不出来。

• 内存优化型实例的硬件配置更贴合数据库需求
  这类实例（比如R5、R6i系列）主打高内存/CPU配比，同时配备高带宽内存，能高效处理内存内的数据读写，完美适配数据库“内存优先”的访问模式。而且多数内存优化实例也支持EBS优化或本地NVMe存储，磁盘IO性能完全能覆盖数据库的持久化需求，不需要单独依赖存储优化型的高IOPS。

• 存储优化型的定位是磁盘IO密集场景
  存储优化型实例（比如I3、I4i系列）是为需要频繁、大量磁盘读写的场景设计的，比如数据仓库的批量分析、日志聚合处理、分布式文件系统等。这些场景的瓶颈确实在磁盘IO，但高性能OLTP数据库的瓶颈不在这——强行用存储优化型，反而会因为内存不足导致缓存命中率下降，拖慢整体性能。

• 特殊例外情况
  如果你的数据库是面向大规模离线分析的数仓场景，或者需要处理高并发随机写入的日志型数据库，这时候存储优化型可能更合适，但这类场景通常不被归类为常规意义上的“高性能数据库”（后者特指低延迟OLTP）。

内容的提问来源于stack exchange，提问作者Havyia Ayv