AWS RDS是否支持将日志文件与数据文件存放在独立磁盘？

首先明确：AWS RDS for SQL Server 作为托管服务，原生没有提供将数据文件（.mdf/.ndf）、事务日志文件（.ldf）拆分到不同独立存储卷的配置入口，你在控制台找不到对应选项是正常情况，不是操作遗漏。

不要直接照搬自建SQL Server的部署经验套用到RDS实例上：

• 自建环境要求拆分数据、日志文件到不同物理盘的核心背景，是规避机械磁盘随机IO（数据读写）和顺序IO（日志写入）争抢磁头带来的性能损耗。RDS底层使用的是云块存储，不存在物理磁头调度的问题，官方默认同卷承载两类文件的架构是经过专门性能调优的，不会天然导致磁盘性能瓶颈。

针对你当前遇到的高PAGEIOLATCH_SH等待、磁盘子系统性能不佳问题，按优先级做以下排查优化：

• 先核对存储性能配额是否匹配业务负载
  RDS的存储IOPS、吞吐量上限和所选存储类型、配置容量强绑定：
  • gp2存储按3 IOPS/GB的比例分配基准性能，IOPS上限16000，单卷吞吐量上限250MB/s，存储容量小于1000GB时无法拿到最高IOPS配额
  • gp3存储支持独立配置IOPS（最高32000）和吞吐量（最高1000MB/s），性能和存储容量脱钩，是目前通用场景的首选存储类型
  • io1/io2为预置IOPS存储，最高支持256000 IOPS，适合IO密集型核心业务
    直接查看CloudWatch对应的ReadLatency、WriteLatency指标，如果读延迟持续高于20ms、写延迟持续高于10ms，首先是存储性能配额打满，优先升级存储配置即可，和文件是否同盘无关。
• 排查数据库层面的IO浪费问题
  PAGEIOLATCH_SH等待的本质是会话等待所需数据页从磁盘加载到内存缓冲区，绝大多数场景下的高等待和存储配置无关，是数据库自身设计问题导致：
  • 检查缺失索引，大量无索引的全表扫描、键查找会产生海量无效磁盘读，是这类等待的最常见诱因
  • 检查实例内存配置，max server memory (MB)参数不要给满实例总内存，需要给操作系统预留10%-20%的内存（最低不少于4GB），避免内存不足导致缓冲区池频繁淘汰数据页，反复触发磁盘读
  • 检查是否存在长时间运行的大查询、事务一次性拉取过量数据占满缓冲区。
• 分流负载压力
  如果业务读负载占比高，可以创建只读实例，将报表、分析类只读请求分流到只读副本，降低主实例的IO压力。

如果你的业务有强制拆分数据、日志文件到独立存储卷的合规或性能要求，RDS托管模式无法满足，需要迁移到EC2上自建SQL Server，自行配置存储挂载、文件路径，这种模式下你拥有完全的实例配置权限，但需要自行承担备份、补丁、高可用搭建、故障处理等全量运维工作。

内容的提问来源于stack exchange，提问作者Eric Mistral