我们正在开发的系统由 Web 应用程序前端和后端组成，后端使用 SQL Server 2008 R2 中的存储过程进行大量数据处理（请不要问为什么……）。这些存储过程大量使用临时表（创建、插入、连接），因此临时数据库写入和读取的 i/o 速率很高。我们的客户需要速度，因此我们即将提出以下建议：
- 购买带有 RAID 1 SSD 阵列的服务器来存储主数据库（如果有钱的话也可以使用 RAID10），使用另一个硬盘来安装操作系统和 SQL Server，以便重要数据以复制形式存储在快速驱动器中，并配备 64 GB RAM。
- 使用 Ramdisk 来存储临时数据库数据库，因此临时表（我们认为是最大的性能瓶颈）在 RAM 中处理。
一些上下文数据：
- 我们的数据库使用量不超过 10 GB，预期增长率非常低。Tempdb 通常增长不超过 2-3 GB。
- 该服务器将用于数据库和 Web 服务器。
- Ramdisk软件可以在windows启动时挂载ramdisk。
我们在一台内存很大的笔记本电脑上测试了 ramdisk 方法。速度至少是显著的（存储过程执行时间缩短至 1/3）。
我需要帮助来确定这是否是一个好的解决方案，并发现我可能忽略的任何缺陷（明显的或不太明显的）。
编辑：感谢您迄今为止的回答！我忘了明确提到会有并发用户使用该应用程序，因此将运行多个临时表操作。此外，混合使用 Web 服务器和 DB 服务器不是我们的选择，我们已经知道这不是最佳选择 ;)
答案1
这不仅仅是速率，也是等待。正确进行基准测试。检查 IOPS 以及磁盘队列长度。使用 Perfmon 和 SQL 分析。继续 - 我会等待。
您已经知道，如果您确实有实际的性能问题，操作系统应该位于一组主轴上，MDF 位于另一组主轴上，LDF 位于另一组主轴上，而 tempdb 文件位于另一组主轴上。如果您不能承诺这样做，请对其进行基准测试并找出您的优先事项。此外，不同的读写模式可以决定每个 RAID 级别的不同。
您可能会发现，具有正确 RAID 配置的标准磁盘可以满足您的需求，而无需使用企业级 SSD。但是，如果 tempdb 受到的打击足够大，单个 SSD 可能就很合适。可能不需要 RAID 来提高性能，但对于冗余来说，这可能是一个好主意。当然，这取决于您的预算以及您可以停机多长时间。
您也知道 SQL 服务器应该与 Web 服务器分开，对吧？如果性能是个问题？即使您现在没有遇到问题，但如果您发展壮大，您将很难确定哪个服务器受到的打击更大，以及适当的修复方法是什么。
答案2
RAID 用于冗余，性能就会受到影响。例如，对于 RAID 5 来说，读取一段数据全部必须读取组件磁盘，并检查奇偶校验（即是比从单个磁盘读取慢，磁头移动不一定会同步，因此你需要等待最长写入操作（即读取全部数据（而不仅仅是平均值））意味着读取所有内容、计算奇偶校验并写入新数据和奇偶校验，这显然比单纯写入要慢。
是的，良好的 RAID 实施和智能操作系统可以大大缓解这种情况（必须这样做，即使单个磁盘相对于 RAM 来说也非常慢，因此任何有价值的操作系统都会无论磁盘如何都进行大量缓存）。
是的，智能 DBMS 还会尽可能地将数据缓存在 RAM 中（尊重对数据一致性、抗故障性等方面的承诺；在需要时，它会明确等待数据安全地存储在磁盘上后再继续）。
对于任何数据库来说，RAMdisk 都是纯粹的毒药（“数据明确写入磁盘，因此是安全的”不是）。
答案3
感谢大家的回答。它们非常有帮助。经过一些后续研究，我发现 I/O 速度并不是这种特定情况下的主要瓶颈，尽管它通常很重要。tempdb 管理的最佳实践包括至少有 4 个数据文件。Microsoft 还建议每个 CPU 核心有 1 个数据文件。拥有更多文件有助于减少某些争用问题。
关于此内容的一些链接：
答案4
因此 tempdb 的写入和读取 I/O 速率较高
RAM 太少。tempdb 仅在溢出时才进行 IO - 否则 SQL Server 不会将 tempdb 页面转储到磁盘。
因此，RAM 磁盘无济于事 - 最好添加更多内存。