这就是我们正在尝试做的事情。
我们将有一个 200GB 以上的 SQL Server 数据库需要加载到内存中。Microsoft 的最佳实践是在服务器上有足够的可用物理内存，然后将整个数据库加载到其中。这意味着我们的每个 SQL Server 都需要 256GB 的内存。这将导致快速访问加载到内存中的数据库，但内存成本很高。顺便说一句，我们在 Windows Server 2008 上运行 SQL Server 2008。
目前，我们的服务器设置为只有 12GB 内存。将近 3GB 分配给操作系统，剩余的 9GB 用于 SQL Server。是否可以将页面文件增加到 256GB 并将其设置在 SSD 驱动器上？然后我们要做的是，将数据库加载到位于 SSD 上的页面文件中。我们希望性能类似于将整个数据库加载到内存中，因为它将位于 SSD 上。
这行得通吗？我们忽略了另一种选择吗？我们希望在不牺牲环境性能的情况下尽可能降低成本。任何意见，将不胜感激。
谢谢。
如果您希望数据库存储在内存中，则需要购买更多内存。尽管其他答案表明，内存是使数据库性能更好的绝对最佳和最便宜的方法 - SQL Server旨在很好地使用内存。
虽然 SQL Server 会在必要时利用页面文件，并且将页面文件放在 SSD 上会比在老式机械磁盘上稍快一些，但它仍然是 I/O 和交换，并且有很多周围的开销，无论下面的磁盘类型如何。一般来说，这可能比在旋转磁盘上拥有相同的页面文件（或根本没有页面文件）要好一些，但我认为它不会有任何影响真正的记忆，或者它会接近你对“快速访问”的期望。
如果您无法购买更多内存，那么您可以从 SSD 上的此页面文件开始，但我相信您还需要关注其他调整机会 - 主要是确保您拥有支持您运行的查询类型的索引，尽可能避免全表扫描。对于全表聚合，您可以考虑索引视图（请参阅此处和此处）；对于子集，您可以考虑过滤索引。
只是为了确定：您将实际数据存储在 SSD 驱动器上，对吗？如果不是，那么我认为您应该将 SSD 用于数据和/或日志，而不是用于页面文件。如果页面文件通过与旋转磁盘交换而不断地交换数据，那么它不会为您提供太多好处。
需要更清楚地了解这个问题。
您是否在控制数据库，或者这是一个限制您优化能力的 COTS 解决方案？
你在集群吗？这就是为什么添加 200+Gb 的 RAM 是一个问题（现在超过 400GB，每个节点 200 个）？
您是使用裸机还是虚拟化？这就是 RAM 可能成为问题的原因吗？
到目前为止，“专家”似乎做出了一些可能对您的情况不公平的假设。
请更新您的问题... :)