使用 RAM 磁盘加速 SQL Server 临时表处理

Question

我们正在开发的系统由一个 Web 应用程序前端和一个使用 SQL Server 2008 R2 中的存储过程进行大量数据处理的后端组成（请不要问为什么...）。这些存储过程大量使用临时表（创建、插入、连接），因此tempdb 的I/O 率在写入和读取中很高。我们的客户需要速度，因此我们将推荐以下内容：

• 购买带有 RAID 1 SSD 阵列的服务器来存储主数据库（如果他们有钱，可能是 RAID10），使用另一个硬盘驱动器安装操作系统和 SQL Server，以便将重要数据与复制一起存储在快速驱动器中，以及64 GB 内存。
• 使用 Ramdisk 存储tempdb数据库，因此临时表（我们认为最大的性能瓶颈）在 RAM 中处理。

一些上下文数据：

• 我们的数据库使用不超过 10 GB，预期增长率非常低。Tempdb 通常增长到不超过 2-3 GB。
• 服务器将用于 DB 和 Web 服务器。
• Ramdisk 软件可以在 windows 启动时挂载 ramdisk。

我们已经在具有大量内存的笔记本电脑中测试了 ramdisk 方法。至少，加速是显着的（存储过程执行时间减少到 1/3）。

我需要帮助来确定这是否是一个好的解决方案，并检测我可能遗漏的任何缺陷（明显的或不太明显的）。

编辑：感谢您到目前为止的答案！我忘了明确提到将有并发用户使用该应用程序，因此将有多个临时表操作正在运行。此外，混合 Web 服务器和数据库服务器不是我们的选择，我们已经知道这不是最佳的 ;)

Answer 1

不只是价格，还有等待。正确进行基准测试。检查 IOPS 以及磁盘队列长度。使用 Perfmon 和 SQL 分析。继续吧——我会等。

您已经知道，如果您确实有实际的性能问题，则操作系统应该位于一组主轴上，M​​DF 位于另一组上，LDF 位于另一组上，tempdb 文件位于另一组上。如果您无法承诺这样做，请对其进行基准测试并找出您的优先事项。此外，不同的读取和写入模式可以为每个模式指定不同的 RAID 级别。

您可能会发现，具有正确 RAID 配置的标准磁盘可以满足您的需要，而不是企业级 SSD。不过，如果 tempdb 受到足够的打击，单个 SSD 可能很适合它。可能不需要 RAID 来提高性能，尽管对于冗余来说这可能是一个好主意。当然，这取决于您的预算以及您可以休息多久。

您还知道 SQL 服务器应该与 Web 服务器分开，对吧？如果性能是一个问题？即使您现在没有遇到问题，但如果您成长了，您将很难确定哪些问题受到更严厉的打击以及适当的解决方案是什么。