我们有一台强大的 Windows 2008 x64 服务器（4 x 4 核 CPU，32GB RAM），运行 SQL Server 2005 64 位。我们有一个很小（6GB）但非常重要的数据库，在页面缓存到内存之前，访问速度有点慢（使用非常随机的 I/O，因此给定页面在内存中的可能性非常低，最终用户会抱怨最初的速度很慢）。磁盘速度足够快（本地 15K SAS），但我猜应用程序编写得有点笨拙（这是一个 COTS 解决方案），所以我想知道是否有办法在 SQL Server 2005 中“强制”将数据库放在内存中（供应商不支持 2008，所以我们不应该升级到 2008），以帮助避免最初的缓存填充问题？
我当前的方法是从脚本中的每个表运行 SELECT * 以获取内存中的数据页，但某些对象（索引、全文搜索等）不会被此方法缓存（并且修改脚本以查询索引并编写适当的 WHERE 子句进行缓存是非常复杂的）。
答案1
不，很遗憾，没有办法强制将数据库放入缓存中。您的强力方法可能是最直接的。您可以使用阈值设置非常低的索引碎片整理脚本来更接近目标，例如，如果索引碎片率为 1%，则重建索引，如下所示：
http://sqlserverpedia.com/wiki/Index_Maintenance
这会花费更长的时间并涉及更多次磁盘写入，但它会产生碎片化索引和更新统计数据的副作用，但无论如何这都是一个好主意。
答案2
好的 - 我无法评论Brent的回答（因为我还没有足够的代表） - 但是如果你要走碎片整理路线，不一定要重建索引 - 因为那将建立新的索引，如果没有足够的可用空间，可能会增加数据库，并保证你的下一个日志备份至少是你的索引的大小，你的日志也可能有大量的日志记录（取决于恢复模型）。如果你要执行碎片整理路线，请执行ALTER INDEX ... REORGANIZE，它不需要任何可用空间（嗯，一个8k页面）但会将叶级读入内存并仅对碎片页面进行操作。非叶级应该在一些查询之后快速进入，并且（取决于扇出）应该比叶级少很多数据。
答案3
为什么数据库对象会从缓存中清除？您是否正在重新启动 SQL 服务或关闭/联机数据库？还是它们被其他数据库的缓存所淘汰？
问候，
单片机。
答案4
我遇到过一些情况，使用 FULLSCAN 更新关键表的统计数据会强制将数据放入缓存，从而使我随后围绕这些表的 DML 速度大大加快。这不是过时统计数据的结果，因为它没有导致执行计划发生变化。